==================================================================== DR 6502 AER 201S Engineering Design 6502 Execution Simulator ==================================================================== Supplementary Notes By: M.J.Malone Quick/Kick Start ================ Use of the Simulator ==================== Some of the dos and don'ts and the reasons for them in using the DR6502 program will be given first. 1) DO put all of DR6502 in on one drive and execute it from that drive. It saves hassles later since it is easier to default to the current drive on all DR6502 files. 2) DO put your .bin file to be simulated on that same drive, same reason. 3) Try not to use pathnames with DR6502. DR6502 does not recognize pathnames. 4) DON'T expect to see any actual input or output when using DR6502 without the hardware simulator card. Without the card DR6502 is a software simulator only that is incapable of real input/output though such operations can and should be simulated through user intervention. 5) DON'T assume there is an error in DR6502 just because your program did not work as expected. Many students have used DR6502 in the past and it has proven to work well, though 2 small bugs were discovered in the most recent YEAR of use. It is very common for students to make errors in logic or be mistaken about the operation of flags for certain instructions. If a genuine error is encountered, the following should be provided: a) A listing of the minimum assembly program required to produce the error. IE 4-10 lines long where every line is required to induce the error. b) The precise keystrokes/commands required to show the error. Such documented errors will be repaired as expeditiously as possible. Starting ======== 1) System Requirements ---------------------- To run DR6502, a machine must be XT or AT compatible and have at least 640K of memory. Of that 640K at least 373K must be free after all memory resident programs and ram disks etc are installed. If there is not enough free memory in your computer, then some of the memory resident programs must be removed or the ram disk must be downsized. page 2 2) Code Requirements -------------------- Produce a pure text file containing your assembly code. Do not use any text editor that encodes the file in any way. If you are using the project computer then remember that your final (target) computer code must start with the following instructions: .ORG $E000 SEI LDX #$FF TXS ; LDX #$00 LDY #$00 InitDelay DEX BNE InitDelay DEY BNE InitDelay ; Your code then follows. The first three statements are used to initialize the microprocessor stack and these are also required when producing a code for DR6502. The next six instructions are a delay necessary to EVERY program used on the project computer. These are required because the project board uses a non-debounced reset switch circuit. Simple debouncing would violate the rise time requirements of the RST signal and more complex methods would require more chips on the project computer board. A small addition to the beginning of every student's program was not considered a problem. At the end of your code you must have: .ORG $FFFC .WORD $E000 .END This sets the reset vector. When the RST (reset) line is used to signal to processor to begin executing, the processor is 'hardwired' to look in memory location $FFFC to find a vector pointing to the beginning of the user program. DR6502 expects to find the reset vector in the same place so these three directives are also required in programs to be simulated. 3) Assembling -------------- Any assembler capable of converting 6502 assembly language statements to a binary file of 6502 machine opcodes and operands would be acceptable. The TASM (Table oriented ASseMbler) is user supported package available to AER 201S students. TASM is a converter of ASC II assembly code files to binary executable files. It is capable of assembling for the 6502 as well as several other processors. It is a common mistake to believe that there is some problem with the fact that the TASM program executes on an IBM type computer but produces code for a 6502 machine. Once again TASM is a page 3 converter program. The machine it executes on does not determine what type of files it produces. TASM could be programmed to run on a Cray but it would still produce code for execution on a 6502 machine. The proper command line for assembling the program 'myfile.asm' in the current directory is: tasm -65 -b -l -fff myfile.asm myfile.bin myfile.lst Note on Options: -65 : Assemble for the 6502 -b : Binary file output -l : List the symbol table -fff: Fill unassigned spaces of the EPROM with $FF This produces a binary file named myfile.bin ready for DR6502 or the EPROM programmer. The files myfile.lst can be used to look at any errors that TASM may have found. 4) Eprom Burning ---------------- This is actually easier than simulating the code so it will be dealt with first. The PC's in the lab that are equipped with EPROM burners have software installed to copy .bin files onto EPROMs. The EPROM burner itself is a card for the PC computers with a cable that leads to the EPROM ZIF (Zero Insertion Force) socket module. You place your EPROM in the socket in the orientation suggested and press the locking lever. Place the disk with your software in the floppy drive and type 'EPROM'. The EPROM burner menu has several options. You should check that the EPROM type and programming voltage match the EPROM you have. Load the file from the disk into the EPROM program's buffer memory starting at address 0000. Check the EPROM is blank by selecting the 'blank check' function from the menu. If the EPROM checks out as blank, select the 'program' or 'copy' from buffer to EPROM' function to program the EPROM. Remove the EPROM and place it in the target computer. If you would like to change the program in the EPROM or if the EPROM did not check out as blank before programming then place the EPROM in the EPROM eraser unit. The EPROM eraser unit clears the program from the EPROM using ultraviolet light on the memory gates. Erasing requires twenty minutes under the ultraviolet light. 5) Writing an EEPROM -------------------- A routine has been written utilizing the hardware simulator interface card, to write data to an EEPROM plugged into a project board RAM socket. EEPROMS must be of the XL2864A type or equivalent. page 4 Simulating a Program with DR6502 ================================ Getting to the Status Screen ---------------------------- To simulate the program DR6502 needs the code and the memory configuration for the target computer. To give this information to the simulator there are two options. 1) Run the CONFIG.EXE program by typing CONFIG, 2) Run DR6502.EXE by typing DR6502 and when it asks if it is configured for the memory of the target type 'n' for no. In this case DR6502 will call the CONFIG program automatically. In the CONFIG program the user will be asked for the type of memory elements and their addresses. When the EPROM is specified, the user will be asked for the name of the .BIN file that will be in the memory of the target computer. DR6502 expects to find this .BIN file in the current directory. Once the configuration is input, CONFIG will automatically call DR6502. This time since you have just finished running the CONFIG program you can answer that 'y' "Yes, DR6502 is configured for the memory of the target". Provided you do not change the name of the binary file in subsequent revisions of your software, there is no need to run the CONFIG program again. DR6502 will next ask if this will be a hardware simulator session. To use DR6502 in hardware mode, the hardware simulator card and the simulator software (DR6502) must be present in the PC. The .BIN and all auxiliary files must be available. The simulator cable must be plugged into the 6502 socket on the target and the target must be supplied with power from a power supply. DR6502 will read several files for information necessary for its operation and then will begin reading the EPROM files. If the hardware simulator is being used the program will ask if the EPROM corresponding to the file is present or not. If the EPROM is not present on the target, the simulator will use the PC's memory to emulate it. The simulator will also ask if there is a symbol file that goes with the .BIN file (a .SYM file produced with DRSYM.EXE and your .LST file) to be loaded into the simulator. It is not necessary to have a symbol file but it does enhance the performance of certain of the simulator's functions. The simulator will next ask what type of processor you are using. The options are 0) - NMOS 6502, 1) Standard CMOS 65C02 and 2) Rockwell CMOS 65C02. The differences between each of these processors is the instruction set. In the newer revisions of the processor, some new instructions were added. Choose the selection that corresponds to the processor that will be in your target computer. page 5 Interpreting the Status Screen ------------------------------ The 'stopped' status screen will then appear and it should look as shown below: --------------------------top of screen----------------------------- (Errors and Warnings Area) ==================================================================== ACC=00 XREG=00 YREG=00 SP=00 PC=E001 Status Register N V u B D I Z C 0 0 1 0 0 1 0 0 ==================================================================== E000 78 SEI (2) Fetch Address =FFFF E001 Next OpCode Vector Address=FFFF Elapsed Cycles (millions):000000.000002 ==================================================================== (Commands area) ---------------------------bottom of screen------------------------- The area at the top of the screen warns of error conditions detected by DR6502 and warns if the opcode stream is becoming unusual. The next area down on the screen shows the current status of the processor registers and the flag register. The next area down on the screen displays information about the current program step. The opcode and operands are shown and then the assembly mnemonic and the addressing mode. If the addressing mode involves a memory fetch then the effective fetch address is shown. If the address mode involves vector indirection then the vector address is also shown. The number of machine cycles since the processor was reset is also shown. Below the lowest bar is the commands area where user commands are input. From the status screen several commands are possible to view or manipulate memory or to start the processor executing in one of several modes: Modes of Execution: (From slowest to fastest) --------------------------------------------- 'Single' Step Mode - While at the 'Stopped' status screen (as shown above) the user can press the 's' key to cause the processor to advance one machine instruction or STEP and return to the 'Stopped' status screen. 'Go' Mode - While at the 'Stopped' Status screen (as shown above) the user can press the 'g' key (for GO) to cause the processor to execute a machine instruction, output all status information and continue on to the next instruction. The 's' key will STOP execution and return the simulator to the 'Stopped' status screen. page 6 'Go Fast' Mode - Since screen output takes most of the time in the execution loop, to speed the processor's progress through uninteresting parts of the code a limited output 'fast' mode is available. By pressing the '`' key in the stopped status screen, the user can cause the processor to enter fast execution where the screen is cleared and only the program counter is displayed on the screen. By pressing '`' again the user can make the processor slow to full output 'go' mode. 'Go Really Fast' Mode - Since even printing the program counter slows execution incredibly, a second fast mode was devised. Often the user knows exactly to what point in the code they would like the processor to run. A 'breakpoint' could be used to halt the processor at that point and the user would need no screen output until that time. As a result when the user has selected a breakpoint and enters '`' 'Go Fast' mode, the processor will clear the screen and enter a completely silent 'Really Fast' mode. There is about an order of magnitude speed difference between 'Go' and 'Go fast' and nearly another order of magnitude between that and 'Go Really Fast'. The following are SOME of the options are available in the stopped menu. Influencing Execution --------------------- 'b' - 'set a Breakpoint' This allows the user to set a point in memory as a breakpoint for execution. If the processor encounters this memory location any time during execution, either as a program location or a data access, execution in the 'go' and 'go really fast' will stop and the full stopped status screen is displayed. 'r' - 'change Registers' The user can modify the contents of any of the 6502 registers including the flags, the processor status register and the program counter. Manipulating Memory ------------------- 'v' - 'View memory' This option performs a hexidecimal display of data space memory so that variables or arrays can be viewed. 'p' - 'Poke memory' This allows the user to input hexidecimal values into memory. page 7 Manipulating Programs --------------------- 'P' - '(re)Program code' This option disassembles one page (256 bytes) of code and displays several lines on the screen. The user can then edit the code with a number of sub-options in the 'P' program option. Changes made to the code are not permanent unless the 's'ave sub-option is selected before the 'q'uit. Display Control --------------- 'm' - 'Monitor a variable' This option allows the user to monitor on the main output screen the contents of a memory location that is an important variable to the program. Summary ======= The previous explanations tried to address some of the common concerns when students approach producing a piece of project software for AER201S. Complete information can only be gained by consulting: TASM documentation DR6502 documentation Project Computer Board Notes There is however no substitute for actually DOING. The sooner a student is completely familiar with the process of moving a code from concept to testing and the implementation, the faster it will go when design iterations become necessary. Design iterations result when software never works at all on the first five tries, and doesn't work completely right until the twentieth or fiftieth revision.