All tool source and binary code can be downloaded here:TOOLS.JAR
The javadoc API for the tools can be found here:JAVADOCS
The tools use the Processor Information discussed here:PROCESSORS
|
The assembler package contains the algorithms and “main” to turn an assembly language text file into a binary file for the target CPU.
* This tool assembles a text file into a binary file and produces an optional * listing file. * * Command line arguments: inputFileName outputFileName [-list] * * Files may be included (recursively) in the input file with the following syntax: * * . include myFile.asm * * The exact syntax of the individual mnemonics depends on the target CPU's * mnemonic set. But there is some common structure for all assembly files: * * The colon ':' is reserved to mark the end of a label. A line may have have only * one label. Labels collapse down to the first line of generated data. * * Origins are labels that happen to be numeric. * * All numeric constants may have an optional base specification. The default base * is decimal. Examples of numbers: "0xFF00" and "123" and "0b00_11_11_00". Note * that '_' are ignored in numeric constants but may be used to separate fields. * * Lines that begin with a "." are defines. A define takes an entire line and is of the * form KEY=VALUE with spacing allowed. * * The program must define 'CPU' before the first opcode. Like: * . CPU = 8080 * or * . CPU = 8080 as Z80,Cish * The "as" clause narrows the mnemonics to just the list given. If "as" is not given then * the instruction set is the processor and the "Cish" set. * * Defines can be generated with an auto-incrementing cursor. For instance: * . VarsBegin = 0x100 * . MyVar1 = # * . MyVar2 = #2 * * The value '#' means use the value of the data cursor and add 1 to the cursor. * The value '#2' means use the value of the data cursor and add 2 to the cursor. * The cursor is automatically set with every numeric define. * * * * A line beginning with '#' is parsed as data. For example: * # 1,2,3,(WORD)4,5,(BYTE)6,0*20,PF0,"This is a test",0 * Once WORD or BYTE is given on a line the following data is the same size * unless overridden. * * The 0*20 means repeat the value '0' twenty times. This is useful for filling. *
* This tool disassembles a binary file into text opcodes for a target processor. * * Command line arguments: binFile cpu [start] [end] [resultMnemonic] * * The 'binFile' is a list of ROM files each with a given origin. For instance: * 0x0000~invaders.h+invaders.g+invaders.f+invaders.e * * This puts the four Space Invaders ROM files together in order. The first file * is given the origin "0x0000" and the others follow right behind it. * * The 'cpu' is the CPU that runs the code. * * The 'start' and 'end' are optional starting and ending points in the disassembly * ROM data. If 'start' is not given then the first address is used. If 'end' is * not given the the last address is used. Leave both out to disassemble the entire * binary collection. * * The 'resultMnemonic' gives the output menonic set for the opcodes. The default is * to use the same CPU as the 'cpu' value. Most of the time this is exactly what * you want to do. But this is useful if you want to disassemble cpu=8080 code but * output the mnemonics as resultCPU=Z80. If you used cpu=Z80 then you would get * Z80 mnemonics in the output in data sections. * * Once a file has been disassembled to text then it can be annotated and run through * ReDiss to change the mnemonic set(s) and spacing. *
The web package contains the code used to create this web site.
The ‘CodeToWeb’ tool reads a commented disassembly file and produces the HTML form complete with a menu at the top, hyperlinks in the code, and labels for identified RAM locations.
The ‘DOCXToWeb’ tool reads the Microsoft Word document containing the write up of a project and generates an HTML version complete with a table of contents at the top.
The tool allows you to “include” text from other files with a complex set of start/stop identifiers. This allows you to “paste in” assembly snippets from the project files automatically. If you change the comments in the file then you only need to rerun the tool to change the write up. You don’t have to maintain the comments in two places.
You may find something in these tools that is useful for you. They have been created for the format of this web site.
There are several “dig” packages that contain tools useful for a particular dig site.
The ‘frogger’ dig contains a tool that converts the music data to human-readable text.
The ‘omegarace’ dig contains a tool to decode the vector graphics used in the game.
All of these tools are interactive code snippets I run from within the Eclipse IDE. You will find lots of fragments commented out or no longer used. These tools are just scaffolding I erected to aid in a disassembly project.