Club Amiga de Montreal

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

/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 283.lha / ReSource_v3.01_Demo / Introduction.doc < prev next >

Wrap

Text File | 1989-09-07 | 37.8 KB | 901 lines

Introduction to ReSource ReSource (C) 1988 Glen McDiarmid The documentation for ReSource is in two parts. This is the introduction, the other is the specifications for each function, in the order in which they appear in the menus. Because ReSource uses functions in the "ARP" library, you must have the file "arp.library" in your "LIBS:" directory when you run ReSource. This file is supplied with both the demo and commercial versions of ReSource, and is available from most BBS's. The version of "arp.library" must be 34 or higher. Because of the large number of functions in ReSource, it was decided to use one-and two-character menu names, so that more menus could be used. Looking from the left, the first menu is "P", which stands for "PROJECT". The real menu name is directly under the one-or two-character name, in capital letters, so should be fairly easy to find them. In all future reference to menus, the full menu name will be used. When describing a function, rather than telling you what key to press to get that function, I'll describe where abouts in the menus that you will find that function. For example, the "Quit" function would be described as "PROJECT/Quit". The function to restore the current file would be "PROJECT/ Restore". You will find both of these under the "PROJECT" menu. Functions in sub-menu boxes will be described in a similar way, i.e. "OUTPUT/Tabs/Spaces". Because any key can have any function bound to it (except "PROJECT/Abort"), key usage will not be discussed, when referencing functions. However, to make it easier to get started, some key bindings will be present, even without loading a keytable: up arrow..............................scroll up one line down arrow............................scroll down line line shift-up arrow........................page backwards shift-down arrow......................page forward right arrow...........................forward reference left arrow............................previous location right-Amiga Q.........................quit right-Amiga O.........................open a file To rebind a key, select "KEY BINDINGS/Rebind key" from the menus, select a function from the menus to have bound, then press the key that you want it bound to. You can overwrite key bindings if you want. When done, you should save the keytable as "RS.keytable". This can be done by selecting "KEY BINDINGS/Save" from the menus. Even both of these functions can be bound to a key, in fact the only function that is not practical to rebind is "PROJECT/Abort", which is always bound to right-Amiga A. Many functions in ReSource operate only on the current line. Because there is no real "cursor", it is necessary to define the "current line": >> The "current line" is the top line, as you see it in ReSource's screen. There may be a section statement to be displayed for the cursor address, this will be shown before the other text, and will force it to be shown on the next line down. If this is not the first section statement in the program, there will be an extra blank line, which will be shown before the section statement. After the section statement, and before the rest of the line, one or more "full-line comments" can be attached. Immediately after the cursor line, any "hidden labels" will be shown. A hidden label may also have a full-line comment attached, which will be shown immediately before it, but after the cursor line. Whenever you scroll up or down a line, all parts of the "current line" will scroll up together, which may be sometimes be visually jarring, if there is many extra lines of text attached. To put it simply, the first "real" line of code or data in the window is the current line. PURPOSE: ReSource was originally just an interactive disassembler, but Version 2 is much more than this. Because ReSource can get its' input from a file, track, or memory, and output all or part to any of these, it is more of a general purpose hacking tool. It can be used to browse through files, without ever bothering to save anything, just to find out what is inside. When you run ReSource, you cannot do anything until you give it something to work on. You can supply the name of the file to load in on the command line: run resource c:popcli Alternatively, you can wait until ReSource starts running, and select a file using the file requester. For full specifications on command line parameters, see below. Providing that there is enough memory available, you can load ANY file into ReSource. If ReSource recognizes it as a load file (one that you can run; an executable program), it will load it, perform any necessary relocation, etc., as if the program is going to be actually run. If the file that you request loaded is not a load file, it will be loaded "as is". Load files may be also loaded "as is", by using the "Load binary" function, in the "PROJECT" menu. This will give you access to the hunk, symbol, and relocation information, that otherwise gets stripped out when the program is loaded into memory. Libraries, devices drivers, fonts are also load files, which means that you can disassemble them, save the assembler source code, do a modification, and re-assemble them. DISASSEMBLING A PROGRAM: To disassemble a program is to interpret what went into the program, to make it work. It can be a very complex and trying task, with practice one can become quite adept at it. There is many different and seperate things to do when disassembling, one of the most important things is to seperate the code from the data. There is only one part of a load file that is guaranteed to be code, and that is at the very start. ReSource has the ability to scan lines of code, looking for references to other parts of the program being disassembled. This is a very useful function, as when a reference is made, it creates a label at that address, which will be used in all future references to that part of the program, no matter where it is referenced from. Even more importantly, ReSource can determine what type of data is being referenced, and be correct (almost) every time. If you intend to reassemble the code, you should still verify the source before saving it, as mistakes will occur from time to time. Before ReSource makes a decision about what type of data is being referenced, it examines many different pieces of information that is available, including the actual instruction that made the reference. There is a few ways of getting ReSource to scan lines of code. The simplest way is by using the "LABELS/Create single/Label - dest". This scans only the current line, and does NOT advance the cursor. If, in a line of code, a reference is made to somewhere within the program, that HASN'T got a label yet, it will be shown as some offset from the label "START", which is imagined to be (but not actually, unless YOU have done it) attached to the first byte in the program. You could create a label called "START", at the first byte in the program, however when you re-assemble, there is a chance that some different length instructions will be used, which will make all references past the first different instruction, inaccurate. Another way to get ReSource to scan lines of code is with the "LABELS/Create multiple/ALL". This function scans the current line, and if ReSource is reasonably sure that it is really code, it will scan it, and move on to the next line. This process will repeat until either the end of file, or until ReSource believes that the current line may not be code, even though it may be displaying as such. After executing this function, if the cursor isn't at the end of file yet, and there is some more code that hasn't been "scanned" yet, you can scroll to the start of the next block of code, and execute this function again, repeating until all code in the program has been scanned. At this point, most references within the program will be to labels, and not use the "START+$xxxx" type of reference. To make sure of this, you can set up a search for "START+", and perhaps scan the lines individually. When all code in a program has been "scanned", generally the next function that you will want to use is "DISPLAY/Fill-in data types". This function does two passes over the entire program, and does NOT shift the cursor. The first pass looks at what data types have been set, and makes some assumptions for all places in the program where the data type has not been specifically set. When you "Set data type", you are telling ReSource "this is CODE", or "this is ASCII", or "these are to be displayed as bytes", etc. Generally, this data type will be assumed from this byte forward, until the next byte that has had the data type specifically set. Many conditions are tested when making decisions about what type of data is where, providing that you have "scanned" all code in the program, after executing the "Fill-in data types" function, the resulting source code will look like source code should look. The second pass in "Fill-in data types" is called "Calculating line lengths" in the title bar. This is used to let ReSource know how far back to go, when scrolling backwards. Also, string lengths are determined during this pass. When you first load in a file, all line lengths are set to two bytes. When scrolling forward, most things will be shown properly anyway, but if you scroll backwards before first doing a "Fill-in data types", a jarry display will result. At this point, if you output to a ".asm" file, it will probably be good enough to re-assemble. However, most people will want to examine the file, and make it more readable, especially if the program needs to be modified. An excellent place to start is by finding where any libraries are being opened, finding where the library base is being stored, and give meaningful names to these data storage locations. Assume that the following code is a small part of a program: MOVE.L 4,A6 LEA START+$06B6(PC),A1 JSR -$0198(A6) MOVE.L D0,START+$0C36 BNE.S START+$06AE MOVE.L #$00038007,D7 JSR -$006C(A6) BRA.S START+$06B2 JSR START+$0142 ADDQ.W #8,SP RTS BCC START+$0727 ???? BGE START+$0725 BHI START+$0730 BSR START+$0732 ???? After scanning all code in this program, it would look like this: MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR -$0198(A6) MOVE.L D0,START+$0C36 BNE.S lbC0006AE MOVE.L #$00038007,D7 JSR -$006C(A6) BRA.S lbC0006B2 lbC0006AE JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'do' dc.b 's.' dc.b 'li' dc.b 'br' dc.b 'ar' dc.b 'y',0 Next, "DISPLAY/Fill-in data types" will be used: MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR -$0198(A6) MOVE.L D0,lbL000C36 BNE.S lbC0006AE MOVE.L #$00038007,D7 JSR -$006C(A6) BRA.S lbC0006B2 lbC0006AE JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'dos.library',0 The astute will have noticed that because the A6 register was loaded from location 4, it will point to the exec library base. Therefore, the third line of this block of code is a call to somewhere in the exec library. By scrolling so that this line becomes the top line on the screen, and selecting the "SYMBOLS/Libraries/Exec", our block of code will look like this: MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR _LVOOldOpenLibrary(A6) MOVE.L D0,lbL000C36 BNE.S lbC0006AE MOVE.L #$00038007,D7 JSR -$006C(A6) BRA.S lbC0006B2 lbC0006AE JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'dos.library',0 Checking the documentation for the "OldOpenLibrary" exec call will tell us that on return, the D0 register will contain the library base for the library just opened, if successful. Because we know that it was the DOS library that was opened, the label "lbL000C36" referenced on the fourth line could now be called "Dos_Base", instead of "lbL000C36": MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR _LVOOldOpenLibrary(A6) MOVE.L D0,Dos_Base BNE.S lbC0006AE MOVE.L #$00038007,D7 JSR -$006C(A6) BRA.S lbC0006B2 lbC0006AE JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'dos.library',0 If the D0 register DID contain a non-zero value, it means that "dos.library" did open successfully, and the following conditional branch WILL be taken. Where this branches to, is labelled "lbC0006AE". A better name for this would be "DosOpenedOkay". Scroll so that the line "lbC0006AE JSR lbC000142" is on the top line of the display, and select "LABELS/Create single/Label". When requested, type in "DosOpenedOkay": MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR _LVOOldOpenLibrary(A6) MOVE.L D0,Dos_Base BNE.S DosOpenedOkay MOVE.L #$00038007,D7 JSR -$006C(A6) BRA.S lbC0006B2 DosOpenedOkay JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'dos.library',0 If the call to "OldOpenLibrary" was unsuccessful, the branch on the fifth line would NOT be taken. In this case, the D7 register is loaded with the value "$38007", and a call is made to the subroutine at offset -$6C from where the A6 register is currently pointing to. We do know that the A6 register was pointing to the Exec library base before, we also know that none of the code executed so far has destroyed the value in A6, so we can safely assume that A6 will still point to Exec library base. Hence, by scrolling so that the seventh line of this block is on the top line of the display, and selecting "SYMBOLS/Libraries/Exec" again, our block will look like this: MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR _LVOOldOpenLibrary(A6) MOVE.L D0,Dos_Base BNE.S DosOpenedOkay MOVE.L #$00038007,D7 JSR _LVOAlert(A6) BRA.S lbC0006B2 DosOpenedOkay JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'dos.library',0 After reading the documentation for the exec call "Alert", we find out that on entry, the D7 register should contain a number representing an alert code. By scrolling so the the line "MOVE.L #$00038007,D7" is on the top line of the display, and selecting "SYMBOLS/A-B/Alert codes", our block will now look like this: MOVE.L 4,A6 lbC000694 LEA doslibrary.MSG(PC),A1 JSR _LVOOldOpenLibrary(A6) MOVE.L D0,Dos_Base BNE.S DosOpenedOkay MOVE.L #AT_Recovery!AG_OpenLib!AO_DOSLib,D7 JSR _LVOAlert(A6) BRA.S lbC0006B2 DosOpenedOkay JSR lbC000142 lbC0006B2 ADDQ.W #8,SP RTS doslibrary.MSG dc.b 'dos.library',0 Examining the include file "exec/alerts.i" will tell us that "AT_Recovery" is used for recoverable alerts, "AG_OpenLib" means that a library failed to open, and "AO_DOSLib" tells us which library is in question. Because this is a recoverable alert, the following line of code ("BRA.S lbC0006B2") WILL be executed, in which case we could change the label "lbC0006B2" to something like "DosDidntOpen", or "NoDosAvailable". This is important, as if any other code in this program makes a reference to one of the labels that we have changed, it too will use the new name. In this example, another part of the program that WAS: lbC0007DE MOVE.L 4(SP),D1 MOVE.L lbL000C36,A6 JMP -$0024(A6) lbC0007EA MOVE.L D4,-(SP) MOVEM.L 8(SP),D1-D4 MOVE.L lbL000C36,A6 JSR -$008A(A6) MOVE.L (SP)+,D4 RTS lbC0007FE MOVE.L 4(SP),D1 MOVE.L lbL000C36,A6 JMP -$007E(A6) And now will be shown as: lbC0007DE MOVE.L 4(SP),D1 MOVE.L Dos_Base,A6 JMP -$0024(A6) lbC0007EA MOVE.L D4,-(SP) MOVEM.L 8(SP),D1-D4 MOVE.L Dos_Base,A6 JSR -$008A(A6) MOVE.L (SP)+,D4 RTS lbC0007FE MOVE.L 4(SP),D1 MOVE.L Dos_Base,A6 JMP -$007E(A6) After using the function "SYMBOLS/Libraries/Dos" a few times, it would become: lbC0007DE MOVE.L 4(SP),D1 MOVE.L Dos_Base,A6 JMP _LVOClose(A6) lbC0007EA MOVE.L D4,-(SP) MOVEM.L 8(SP),D1-D4 MOVE.L Dos_Base,A6 JSR _LVOCreateProc(A6) MOVE.L (SP)+,D4 RTS lbC0007FE MOVE.L 4(SP),D1 MOVE.L Dos_Base,A6 JMP _LVOCurrentDir(A6) To continue, we would replace a few labels: CloseSUB MOVE.L 4(SP),D1 MOVE.L Dos_Base,A6 JMP _LVOClose(A6) CreateProcSUB MOVE.L D4,-(SP) MOVEM.L 8(SP),D1-D4 MOVE.L Dos_Base,A6 JSR _LVOCreateProc(A6) MOVE.L (SP)+,D4 RTS CurrentDirSUB MOVE.L 4(SP),D1 MOVE.L Dos_Base,A6 JMP _LVOCurrentDir(A6) Okay, so far so good. Now, where the line: JSR lbC0007FE used to be, it would be replaced by: JSR CurrentDirSUB This happens automatically, whenever you replace any label. The process helps itself; the start is the hardest, the rest come fairly easily. In general, where a label is used, if you have any idea of what is happening at all, you should replace it with a label that will remind you of what the code is doing. It doesn't matter what name you use (as long as it is a legal label for the assembler that you plan to use), if necessary you can replace it with something better later on. MENUS: The menus in ReSource fully support drag-selecting, and multiple selection. Many options within ReSource have a "checked" menu, which in most cases is "hot". This means that even though ReSource may be busy doing something, if you select something in the menus that will effect the current operation, it will take effect IMMEDIATELY. For example, while saving the source code to a ".asm" file, if you select "OPTIONS/SYMBOL/OFF", from that point on, the output file will not show any symbols. Similarly, if you selected "OPTIONS/DCB statements/ON" during the save, DCB statements would be used in the output file from that point on. This feature is handy during the execution of macros, as you will see in the section on macros. *********************************************************** KEYS: As mentioned previously, any function except the "PROJECT/ Abort" function can be bound to any key. All non-qualifier keys can be used, with or without any of the following combinations of qualifier keys: shift (left or right, or caps lock, all treated as one) alt (left or right, both treated as one) ctl left Amiga right Amiga shift-alt shift-ctl alt-ctl shift-alt-ctl For example, to rebind the "open file" function to right- Amiga O, select "KEY REBINDINGS/Rebind key", then select "PROJECT/Open load file", then press and hold down the right Amiga key, press and release the "O" key, and finally release the right Amiga key. From then on, instead of using the menus for opening a file, you could just press right- Amiga O. To make this binding permanent, you should save the current bindings, to a KEYTABLE. Select "KEY BINDINGS/ Save", and type in the name of a file to save the key bindings to. If you want these bindings used every time you use ReSource, you should save the key bindings as "RS.keytable". With many programs, when you press and hold down the down arrow key, to scroll down, a backlog of key repeats will form, making it difficult to stop the scrolling, even after releasing the offending key. Where this would be problem, the repeats are flushed, making control by keys better. LOADING: There are five functions that deal with loading, these are "PROJECT/Open load file" and "PROJECT/Open binary file", "PROJECT/Restore", "PROJECT/Dismble memory" and "PROJECT/ Read tracks". The first of these will examine the start of the file, to check if it is an Amiga load file. Amiga load files include all executable programs (excepting those using overlays), libraries, device drivers, and fonts. With this type of load, ReSource examines, then strips out, all hunk, relocation, and debug symbol information. This information is not lost, it is used internally to ReSource, to make better decisions about data type setting, etc. To load a file, ReSource sometimes requires a great deal of memory, especially when disassembling large files. For any file, the approximate memory requirements is 6 to 10 times the size of the file. As a further requirement, much of this is required to be continuous. ReSource is NOT practical on a 512K machine. If you have 2 Megs of fast memory, you will be able to disassemble most programs. Any debug symbols will be shown as labels in their respective places with the program, even the relocation information is available. For example, if you select "DISPLAY/Hiliting/Reloc32", any relocated pointers are hilited. When disassembling, this information is quite valuable, as it helps you to tell where code is, where tables of pointers are, etc. ReSource also makes heavy use of this information in many functions, and is one of the main reasons that it is so accurate in determining data types, especially when telling code from ascii. The hunk information also tells you whether something was meant to load to chip memory, which immediately lets you know that it is probably graphics or sound data. If a program has the debug symbols left in it, it makes the disassembling process much easier. When the file is loaded, for each debug symbol found, if it is nine characters long, starts with "lb", followed by an upper case "A", "B", "C", "L", or "W", at the point that the label is attached, the data type will immediately be set to ascii, bytes, code, longwords, or words, respectively. Thus, if you have to disassemble a program that you previously disassembled, then reassembled, most of the data types will be set for you, as the file is loaded. There is one other type of file that can be loaded in using "PROJECT/Open load file", it is the ReSource data file, or ".RS" file. It is discussed in detail in another section. If ReSource cannot load the file as an Amiga load file, it will automatically attempt to load it as-is, without looking for hunk, relocation, and debug symbol information. If it is an Amiga load file, but has been corrupted, ReSource will refuse to load it. You can still load it, however, using the "PROJECT/Load binary file" function. With this function, you can load any file, provided that there is enough memory to load it. This is handy for disassembling operating systems, text files, or even normal Amiga load files. In this case, you may wish to examine the hunk information inside an Amiga load file. The "PROJECT/Restore" function will attempt to load the same file that you loaded last, this is useful when you "stuff up", and just want to start again. The restore function is only usable when you loaded a file, NOT when you disassemble memory directly, or read tracks from a floppy disk. When you open a file, and you are asked to select a file using the file requester, you can cancel the load straight away, and retain the current file. If you hit the "okay" gadget, and the file is not successfully loaded, (perhaps because it is too large for available memory), you have lost your current file. If at this time, you select "cancel", ReSource will give you the chance to quit, in case you cannot or are unwilling to load any file. If you don't quit, ReSource will again offer the file requester, where you may select a file to disassemble. *********************************************************** DATA FILES: The ReSource data file, or ".RS" file, is a file containing most of the data areas internal to ReSource, while any particular file is loaded. This is used to save your work, and later load it back into ReSource, so you can continue disassembling a program some other time, without losing any of what you have already done. You could even send this file to a friend, assuming that he/she has purchased ReSource. This should be particularly useful in disassembling the Amiga operating system (Kickstart), as the Kickstart .RS file does not contain any copyrighted material, and so can be legally distributed. Be aware that you will require at least two megs of fast memory to load a Kickstart .RS file. Even the cursor position is saved in a .RS file, making it easy for you to remember what you were doing last when you saved the .RS file. The .RS file is only recognized with "PROJECT/Open load file", not the "PROJECT/Open binary file". It is the content of the file that allows ReSource to recognize a .RS file, not the name of the file. However, the file should have an extension of ".RS", so that it is immediately recognized by humans as a ReSource data file. To save your work (doesn't matter how you loaded it), select "PROJECT/Save .RS", and select a filename to save to. OUTPUT: Eventually, after disassembling a program, you will probably want to save it to a text file, that you will later assemble, perhaps after doing some modifications. By using the "OUTPUT/Save .asm" function, the entire file can be saved as a text file, exactly as you see it on the screen. If you only wish to save part of the file, use "OUTPUT/Save .asm/Partial". Another function dealing with output, is "OUTPUT/Save binary image". If you originally loaded a file as a binary image file, using this function will save the file exactly as it was loaded. While this may at first seem to be useless, consider that the cursor address in ReSource can be shown as an absolute address, and that a program running in the background (such as Metascope) could perform modifications to the file, by overwriting the current information. For example, if you have a program that has some annoying feature, you could quickly find the offending code with ReSource, find out the absolute address of the cursor (DISPLAY/Cursor address/Absolute), then simply overwrite the offending code with "NOP" instructions. Once this has been done, select "OUTPUT/Save binary image", and you can use the file immediately, without going through the complete disassembly/re-assembly/link process. To find out how large the output .asm file will be, you can select "OUTPUT/Calculate .asm size/ALL". This will tell you the output size, in bytes, K's, and as a percentage of a floppy disk (which may be larger than 100%). If you change any of the options, it will most probably have some effect on the size of the output file. To make the output .asm file smaller, most things in the "OPTIONS" menu should be switched OFF, except for "DCB instructions", which if used, can shrink the size of a .asm file considerably, especially if there are large data areas. Selecting OUTPUT/Tabs/Real tabs will also make the output file size smaller, as will DISPLAY/Blank lines/OFF. If the size of the output file is not a problem, then switch these options to suit your tastes. When you create a symbol, unless you have set OUTPUT/Symbol table to "None", the symbol and its value will be stored, so that a symbol table can be created at the beginning of the output source code file. This symbol table can take the form of an equate table i.e.: AG_OpenLib EQU $00030000 AO_DOSLib EQU $00008007 AT_Recovery EQU $00000000 _LVOAlert EQU $FFFFFF94 _LVOClose EQU $FFFFFFDC _LVOCreateProc EQU $FFFFFF76 _LVOCurrentDir EQU $FFFFFF82 Alternatively, it can take the form of an "XREF" table i.e.: XREF AG_OpenLib XREF AO_DOSLib XREF AT_Recovery XREF _LVOAlert XREF _LVOClose XREF _LVOCreateProc XREF _LVOCurrentDir While you are creating symbols, it matters only if you have set the OUTPUT/Symbol table option to "None", whether it is "EQU" or "XREF" at this time is not important. The symbol table is also stored in a .RS file. When it is time to create the .asm file, you can select either "EQU" or "XREF" as the type of symbol table to create. Even though you may create many symbols with the same name, the symbol table will contain only one entry for each symbol. Thus, it will correctly assemble with most assemblers. Either real tabs (ASCII value 9) or space may be used in the output file. *********************************************************** DISPLAY: To cater for differing tastes, how ReSource goes about displaying information can be varied dramatically. Overlong lines may or may not wrap around, code may be shown in upper case, or lower case. Data declarations can be shown in upper case or lower case. You can have blank lines appear after conditional branches, after all branches, or none at all. Any number can be shown in hexadecimal, decimal, binary, or ASCII, if within the required range. Numbers below 10 in value can be globally converted to decimal, numbers below 16 can be globally converted to decimal, or none. Each line that doesn't start with a label can instead show the current offset. Section statements, the END statement, labels, hidden labels, symbols, and two types of comments can be individually be set ON or OFF at any time. The settings of these options can be made permanent by selecting the required functions in Macro #19 (the last local macro), and saving the macro table as "S:RS.macros". See the section on macros for more information. Selecting the function "OPTIONS 1/Labels/OFF" does NOT remove any labels, it simply stops them from being shown, until you select "OPTIONS 1/Labels/ON" again. For example, you might wish to search for "lbC" as a string inside a comment, unless you turn labels off, you will have to spend a long time searching for the real target, as many labels will start with "lbC". SEARCH: ReSource has some very powerful search functions. You can select from a normal search, or a pattern search. You can search forwards, backwards, or a special combined search, that searches in both directions at the same time, which will find the "nearest" occurrence of the search string. For use in macros, you can also search just the current line, or the accumulator. The text that you see on the display will be the text that will be searched through. For the purpose of searches, tabs are set to real tabs, not spaces. Thus, if you wish to search for: MOVE.L #100,D0 , you would press "tab" where you see spaces in the above line. When using the pattern search, the wildcards are those used in all ARP programs. For completeness, they are repeated here: *********************************************************** ARP and Wildcards ARP has an extensive set of wildcards, and most ARP programs allow them to be used. ARP supports ALL of the AmigaDOS set of wildcards, as well as the more standard Unix* style of wildcards. ARP supports the following wildcard characters, note that these are valid inside or out of quotes: (a|b|c) Will match one of a, b or c. These can be patterns. ? Matches any single character #<pat> Pattern repeated 0 or more times, in particular, #? matches anything. [char] A set of characters, for example, [abc] or [a..c] specify the same set. [^char] Match everything but this set of characters. * 0 or more occurrences of any character. These can be used in combination, of course, so that *.(c|h) or *.[ch] will match any filenames ending in either .c or .h proceeded by any number of characters, including no characters. For example, if you want to search for "JSR" or "BSR", you would specify "?SR" as the search pattern, and you would use the pattern search, not the normal search. Here's some more examples: lb[ABCWL] . .......would find any occurrence of "lbA", "lbB", "lbC", "lbW", or "lbL". "lbM" would NOT constitute a valid match. J(MP|SR) -$????*(A6*) . .......would get a match on the following lines: JMP -$00C6(A6) JSR -$00C6(A6) JSR -$01FE(A6) JMP -$FFFF(A6) but not on the following lines: JMP $00C6(A6) JSR -$00C6(A5) JSR $1FE(A6) JMP (A6) Note that a real tab character was used above, between "J(MP|SR)" and "-$????$A6$". During a search, whether tabs are set to real tabs, or spaces, is not important. *********************************************************** COMMAND LINE PARAMETERS: ----------------------- When you run ReSource from a CLI, you can supply a parameter, so that ReSource can gets its input straight away. Examine the following examples: ReSource c:popcli (The program "popcli" will be loaded as a load file, from the C: device) ReSource libs:arp.library (The file "arp.library" will be loaded from the libs: device, as a load file) ReSource *b c:popcli (The file "popcli" will be loaded as a binary image, from the C: device) ReSource * (Kickstart as it appears in memory is loaded) ReSource *m $FC0000 $FD0000 (The first 64K of Kickstart will be loaded) ReSource *DF0: 0 0 1 (The boot sector from DF0: will be loaded, a total of 512 bytes. Use this to check for/disassemble viruses) ReSource *DF1: 40 41 (The entire directory cylinder from DF1: will be loaded, 11K in all) ReSource *m $400 $800 (For most Amigas, this will load the exec library) ReSource *m 0 1 (Load one byte of memory, at location zero) *********************************************************** Amiga, AmigaDOS, and Kickstart are registered trademarks of Commodore-Amiga, Inc. ***********************************************************