Edit Mode is entered directly from the menu. The screen is a 40 x 24 window on the source program. Function keys allow you to move this window to the right or left in charater increments, or up and down 24 lines at a time. Since most of my assembler programs have fewer than 40 characters per line, I tend to view the leftmost 40 characters and make heavy use of the up and down scrolling.
The four cursor keys are enabled in Edit Mode, making it especially easy to correct typographical errors. Whole lines can be inserted into the text by moving the cursor to the adjacent line and pressing the Insert function key; a new blank line is inserted, and the user simply types in the new line.
Similarly, a whole tine can be deleted by moving the cursor there and pressing the Delete function key; the line is removed and the line numbers of the following lines are automatically decremented. There are also keys for inserting or deleting characters. A Tab key is also provided for tabbing to columns 8 and Edit Mode makes it very easy to enter new programs, because the user can both type the source program in a natural manner, and correct errors and omissions as they occur.
Edit Mode is exited via the Back function key, which puts the editor into Command Mode. Line 2 is reserved for parameters to be input by the user, so in this mode the text window is 40 x Most options require further information to be given on line 2, and very clear prompts are given so the user knows what to enter. Each option is selected by typing the first character of the option name.
For example, to find an occurrence of a string in the source program, the user enters F. The Replace option is like the Find, except that each specified occurrence of the string is replaced by a second string given by the user. Note that -g splits based on GROM directives, and not by size. The name parameter -n overrides the default name of the program that shows up in the TI 99 menu selection screen.
Again, we recommend -c only for very simple programs, and suggest using plain byte code instead. The text option -t creates a textual representation of the byte code. The text format can be specified similarly to xas The listing option -L creates a list file that shows the addresses and byte values for each source line. When -L is given, the symbol dump option -S includes the symbol table in the list file. The include path option -I , the define option -D , the quiet option -q and the symbol dump option -E work identical to their xas99 counterparts.
As the Graphics Programming Language was never intended for public release, existing tools for assembling GPL source code differ substantially in the syntax they use. We can choose other syntax styles, however, with the syntax parameter -y. Currently, the only extra syntax is the syntax of the TI Image Tool disassembler, available with name mizapf named after the creator of the image tool.
The native xga99 syntax style is more "modern" in that it supports lower case sources, extended expressions, relaxed labels, local labels, and relaxed use of whitespace, including the relaxed syntax mode, similar to xas Both cross-assemblers also share the same preprocessor. As for xas99 , warnings and errors are colored by default, which may be controlled with the --color option.
For details, refer to xas Note that indexes must be located in scratchpad RAM. Labels, even when attached to instructions, do not represent any memory type. We could thus use any address prefix on any label, which on the other hand implies that we must use G in MOVE instructions:. The only exceptions to this rule are branch and call instructions, where the address prefix G is optional:.
And just as we can tag labels in expressions with any address prefix, we cannot endow a label with a type:.
Expressions are evaluated left-to-right with equal operator precedence; parentheses may be used to change the order of evaluation. For further details, please refer to the xas99 section on expressions. Finally, we can choose other styles with the -y option. The TEXT directive generates a sequence of bytes from a text literal or an extended hexadecimal literal. You can specify either the GROM number 0 , The cartridge option -c implies -G 0x and -A 0x A binary file is translated as a sequence of BYTE s.
All extensions are backwards compatible so that any existing source code using suitable syntax should assemble as-is. The xas99 extensions regarding comments , labels , local labels , whitespace , relaxed syntax mode, expressions , external symbols and the preprocessor also apply to xga The cross-disassembler xda99 is a command-line tool to convert machine code back into assembly source code.
As an example file for this section, we will use ascart. To disassemble a binary machine code file, we need to tell the disassembler the first address of the machine code with address option -a and the starting address for the disassembly with "from" option -f :.
All command line values are interpreted as hexadecimal values. The resulting file ascart. We see for each addresses the contents and the assembly instruction located at the address. Words showing? The output option -o redirects the output to a different file, or prints to stdout when using the special filename -. We can also specify an upper bound on the range to disassemble with the "to" option -t. By default, xda99 disassembles TMS machine code.
We can, however, extend the recognized opcodes to TMS and F18A by supplying options -5 or , resp. The skip option -k skips some bytes at the beginning of the binary to disassemble. Machine code consists of both code and data segments, which are often intermingled. Without context information, however, a disassembler cannot tell data from code. Using xda99 with the from parameter -f will start the disassembly in top-down mode , which disassembles sequentially word by word.
This mode often yields bad results, as data segments will be translated into meaningless statements. For example, if we change the from address in the ascart. For some kinds of data, we can spot if the data was disassembled erroneously, as the resulting source often contains uncommon mnemonics and operands with complex address formats and random-looking addresses.
The situation gets worse when disassembling data into nonsense statements spills over to the real code, e. If the data segments are known, those can be excluded from disassembly with the exclude option -e. The upper address yyyy of an exclude range xxxx-yyyy is not included in the range, so range is an empty range. Range addresses should always be even. For unknown programs, excluding data segments is difficult. Thus, xda99 offers an additional run mode -r that observes static branch, call, and return statements, and disassembles only along the program flow.
For the ascart. For convenience, the special run start address start denotes all start addresses derived from the machine code. Thus, the above line becomes. Currently, start only works for cartridge images containing a GPL header. In all other cases, start defaults to the address given by -a. Run mode adds jump marker comments to the output that show from which address a given instruction was branched to:.
The program option -p turns the disassembly into actual source code that can be re-assembled again:. The -p options will also include an EQU stanza of all symbols used, in this case all xas99 internal symbols that were imported with REF by the program. To use more symbols, a symbol file can be supplied with the -S parameter.
The symbol file can be generated with the EQU option -E of xas99 , or written manually in a fairly free style, e. Data segments often contain strings, that can be restored heuristically by using the string option -n , either with or without the -p option. Option -n tries to find strings in un-disassembled areas. Thus, -n is only useful in run mode or top-down mode with exclusions, as otherwise top-down mode will not leave behind any data segments where strings could be found.
The concise option -c ignores all non-disassembled addresses in the output by merging those addresses marked by? The register option -R tells the disassembler to use plain integers for registers, i. When the run mode disassembler hits an address which has already been disassembled, it stops the current run.
This regularly happens for multiple calls to a subroutine, loops, or recursion, and is perfectly normal. The latter remark is more relevant for xdg99 , where BR is often used as a shorter B. As a consequence, a run may "run off", and worse, different runs may try to disassemble the same range differently:.
Above, the second run hits an address that is only part of a previously disassembled address i. The default behavior of xda99 is to stop the run, leaving the previous disassembly untouched.
You can override the default with the force option -F , which will always overwrite previous results. There is no recommendation to disassemble with or without force. The result of each disassembly may vary with each binary, and should be tried out.
In general, we should not expect an optimal result by invoking xda99 just once. Instead, disassembly is an iterative process, where the run mode will continuously uncover new code fragments, and where previous disassemblies have to be revised as we gather new information about the program. In fact, at some point in the future, both programs might be merged into one. The only option that xdg99 features over xda99 is the syntax selection option -y , which is already known from xga99 :.
At the same time, the -R option of xda99 has no meaning for GPL, and thus is not supported by xdg Programs in source or listing format are plain text files that contain the BASIC statements that a user would type in. These kind of text files are usually not stored on a floppy disk.
Typical use cases for xbas99 include the listing of programs stored in internal format and the creation of program files for the BASIC interpreter from a text file with BASIC statements. BASIC programs in long format are detected automatically. To list programs in merge format, we must add the merge option --merge.
Merge format is currently not detected automatically. The create option -c assumes that each line of the text file contains exactly one line of the program. If the listing has been formatted with a fixed line width, e. To join split lines, we can use the join option -j. Since xbas99 does not perform a syntactic analysis, the program cannot tell if the line starting with is the continuation of the previous line or the next program line with line number To handle this situation, -j has an optional parameter.
In the example above, the first value would be 2, because we have no program line wrapped over three or more text lines, and the second value would be 10, since the difference between two consecutive line numbers is always If we want to provide only one of these values, we can write 2, or , Since the biggest line number difference is 10, xbas99 knows that for the line starting with , the cannot be a line number, and thus the line must be part of the statement starting with There are additional heuristics that xbas99 applies, e.
If a translation using -j fails, we need to join the lines manually. A label has to start at the beginning of the line and must end in a colon. Other lines must be indented by at least one blank.
Note that -c will convert label-based programs into regular line number-based programs, so decoding -d will never yield a label-based program. The long option -L instructs xbas99 to create the program in long format. Long programs are stored within the 32 KB memory expansion and may be larger than conventional programs. The creation of programs in merge format is currently not supported. The protection option --protect will add list protection to the generated program. Note, however, that the print option -p of xbas99 will not honor the protection flag.
Advanced users of xdt99 may also combine the creation of the BASIC program file and the transfer to a disk image into one single step using a pipe:. All tools in xdt99 follow the convention that the special filename - denotes stdin or stdout , depending on context. Also note that xbas99 will read and encode any text file that we supply, with only minimal syntax checking. A future version of xbas99 may contain more advanced syntax checks to assure that only correct programs may be tokenized.
The tool can also create files for the SDD 99 hardware extension. When we invoke xdm99 without any options, the tool prints the file catalog of the disk image to stdout :. The top line shows the name of the disk, protection status, the number of used and free sectors, and the disk geometry. For each file, the number of used sectors, the file type, the file length, the number of records, and the protection status is shown.
If present, the file creation or modification time is also shown. Files affected are flagged with ERR in the catalog. In such cases, we can use the repair option -R to automatically try to repair disks with inconsistencies. The extract option -e extracts one or more files from the disk image to the local file system. The local filename is derived automatically from the TI filename by lowercasing.
If we want to keep the original filename as it was on the disk, we can use the TI-style name option -N. To print the contents of a file to stdout , the print option -p may be used. Note that -p is equivalent to combining parameters -e and -o -. This will extract all files matching the given pattern. Note that on Linux and macOS platforms, we have to quote our glob pattern to prevent the shell from expanding the pattern prematurely.
Extracting files will yield the file contents only. In we also want to retain the metadata, i. The add option -a adds local files to the disk image. The syntax for -f is fairly permissible, e. If we add multiple files with -a and specify a name with -n , all files will get that filename, but with the last character incremented for each file. For each file to rename, we have to provide the old and the new filename, separated by a colon :.
To rename the disk itself, we use the -n option without -e or -a options. Note that the deletion is "secure" in the sense that the contents of the deleted files cannot be found anywhere on the disk after the deletion. The write protection parameter -w toggles the current protection status of the given files. Note that file protection affects only TI 99 systems and emulators, and will be ignored by xdm Modifying file operations, such as -a , -r , or -d , do not retain the overall sector structure of the disk.
In particular, for all such operations, the disk image will be automatically defragmented. Simply cataloging the disk or extracting a file, however, will not modify the disk image. By default, all modifying disk operations will change the disk image directly. To create an independent copy of the original disk image with the changes applied, the -o option may be used.
As we already mentioned, extracting files from a disk image to the local file system will lose certain TI-specific information, such as the file type or the record length. Both formats use a header of bytes containing filename and file properties.
Note that xdm99 will not infer the format automatically, so if we forget to supply -t or -9 when adding files, the metadata of the files will be stored on the disk image as part of the file contents. Classic 99 will use long files, but ignore the stored filename. Thus, for Classic 99, we should set the actual filename to a TI-style filename. We can easily do this with the TI-style name option -N when extracting files with -t and -e. Renaming the file will not change the TI filename.
The -N option changes the host filename, not the TI filename. Since plain files lack metadata information, we need to add that data with the file type option -f and the name option -n. We can still override the format with -t or -9 , though. The check disk option -C analyzes a disk image for errors and prints a summary to stderr. While all disk operations, including cataloging, also check and report any disk errors found, the -C parameter restricts the output of xdm99 to those errors only.
The -C parameter also causes xdm99 to set its return value to non-zero for warnings, making it simple to write shell scripts for batch processing bad disk images.
The disk repair option -R tries to fix any disk errors, mostly by deleting erroneous files from it. The repair operation is likely to cause data loss, so it is best to extract erroneous files beforehand or to specify an alternative output file with -o.
The initialize option -X creates a new, blank disk image, using an optional name provided by -n. The size of the disk image is given by the number of sectors. You can combine -X with other parameters such -a to work with the newly created image immediately:. The disk resize option -Z will change the total number of sectors of the disk without changing the contents of the files currently stored. An integer argument will not change the geometry information of the disk.
To change both size and geometry, -Z also accepts a disk geometry string:. The geometry option --set-geometry explicitly sets the number of sides, the density, and the number of tracks of the disk image. The --set-geometry command is rarely required for regular images but may be helpful for experimenting with non-standard disk image formats. The sector dump option -S prints the hexadecimal contents of individual sectors to stdout.
This can be used to further analyze disk errors or to save fragments of corrupted files. The xhm99 HFE image manager is an extension to the xdm99 disk manager that is both a conversion tool and a manager for HFE images used by the HxC floppy emulators. Each option takes an arbitrary number of files.
All options other than -F and -T are similar to those of xdm99 and operate directly on the disk image that is contained in the HFE image supplied. We can create new HFE images with the initialize option -X. Again, we can combine -X with other options. The resize argument -Z can even change the number of tracks, e.
For further information about available arguments, please refer to the xdm99 section. All options require a device name and list of volume numbers. The device name is the name or the port our CF card is connected to.
Device names differ by platform, as well as the method to find out what the correct device name is. Note that we need to be Administrator or root in order to access the device.
On Linux, we can use sudo , and on Windows, we should start the cmd. Note that the device names listed above are examples only. We need to run above commands every time after we insert a CF card , since the device name can change depending on how many devices are connected. Loading memory images is particularly fast, but comes at the cost of flexibility.
The program code is not relocatable anymore and must be previously saved as a memory image. Unlike programs loaded by option 3, memory images cannot rely on external utilities, so all required utilities must be included.
After TI exited the market the bug was fixed but many disks remain with the error remaining. This difficulty was not intended behaviour and can be traced to a routine in the file ASSM2 using the wrong register. Consequently, the assembler looks at R1, and the program uses an incorrect name length when scanning for the device name! Adding the period causes the routine to exit, and "catches" the error. Want to fix it? It is usually in the 8th sector of the file.
Change that last C1 into a C0 and the Assembler will work as it is supposed to! No need to add a full stop after PIO now!
0コメント