💾 Archived View for spam.works › mirrors › textfiles › programming › dr6502.txt captured on 2023-06-16 at 20:09:51.
-=-=-=-=-=-=-
DR6502
======
A 6502 Software and Hardware Execution Simulator System
=======================================================
with Code Debugging
===================
Using a Symbolic Assembler/Disassembler
=======================================
By: M.J.Malone
====================================================================
DR 6502 AER 201S Engineering Design 6502 Execution Simulator
====================================================================
Simulator Manual By: M.J.Malone
Contents Page
-------- ----
1) Introduction 1
2) Simulator Modes of Operations 4
3) Stopped Mode Simulator Command Options 6
4) After The CRASH: Simulator Command Options 8
5) DRSYM and Debugging with the Symbolic Assembler/Disassembler 10
6) Explanation of Commands 12
7) Extended Instruction Set for the 65C02 and Rockwell R65C02 22
8) Differences Between DR6502 and the R6502, 65C02 and R65C02 23
9) DR 6502 Support Files 25
10) References 26
Appendix A: OpCode Alignment 27
Appendix B: Merging with EDIT/Blackbeard 30
Appendix C: Hardware Simulator Diagrams 31
DR6502 - A 6502 Software and Hardware Execution Simulator System
==================================================================
with Code Debugging Using a Symbolic Assembler/Disassembler
===========================================================
1) Introduction
===============
What is the Simulator and how does it work?
-------------------------------------------
The 6502 is a digital circuit. Its reactions to logic levels
in interior registers and external memory locations are fixed. If
the logic levels are all known in advance then the operations of the
6502 are determined. The simulator, using the same information as
in a project target computer, traces the execution the 6502 would
take. The simulator is a piece of software that runs on an IBM
compatible computer. The simulator is programmed with the
instruction set of the 6502. The task of tracing the movements a
6502 would make through a piece of code is tackled in the same way
as any other computational problem. The fact that the IBM does not
use the 6502 as its central processor is not relevant.
The hardware simulator is an interface card and cable that
plugs into the 6502 socket on an aerospace project board. The
simulator software, if informed about the presence of the hardware
card, uses it to perform reads and writes on the target computer's
memory. This causes data to actually be read from and written to
I/O ports allowing software debugging while the project hardware is
present.
Memory Management
-----------------
The simulator is a compiled BASIC program. It uses BASIC
variables to keep track of the processor registers and flags. The
program 'grabs' a 160K chunk of a 512K IBM computer's high memory.
Note that the operating system of the IBM is not consulted about the
allocation of this memory and problems can occur. If you have only
256K the area of memory used simply does not exist. If you have a
large number of memory resident programs that push the simulator
code up into this area then the code will corrupt itself and will
once again not work. 64K of that memory is used to record all of
the data in the 64K address space of the 6502 if the hardware
simulator card is not present. Another 64K is used to hold a status
number for each memory location that indicates whether the memory is
allocated, whether it is EPROM or RAM if it is RAM, whether a value
has been written to it or not. This status number will also
indicate if the corresponding memory location is to be found in the
IBM's simulated 6502 address space or found via the hardware card on
the target computer. This makes partial hardware simulation easy
where some of the memory elements are accessed by the hardware board
and others are assumed to be in the simulated address space. One
example of this is EPROM emulation where the simulator accesses the
real RAM and VIA on the target but looks to the IBM memory for the
page 2
program. The last 32K is used for internal variables and data. As
a result, to run the simulator a system must have at least 373K of
the lower 640K free:
DR 6502 Code 85K
Extra Data 160K
512-640K Unused 128K
-------------------------
Total Required: 373K
Included among the files on the DR6502 disk is a program 'MM.COM'
which will tell the user how a system's memory is allocated. To run
DR6502 it must respond with more than 373K free. If not, the
AUTOEXEC.BAT and CONFIG.SYS files must be altered to remove some of
the memory resident utilities or a RAM drive. Also included are two
handy memory management utilities, 'MARK.COM' and 'RELEASE.COM' to
mark a spot in memory and then later to release any memory resident
utilities added after the mark.
The Procedure: What do you have to do to make it run?
-----------------------------------------------------
As explained in the 'QIKSTART.DOC' file, the command line to
use in assembling 'myfile.asm' with TASM is as follows.
tasm -65 -b -l -fff myfile.asm myfile.bin myfile.lst <enter>
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
After the program is assembled, to produce a symbol file for
DR6502, the user must run DRSYM.EXE as follows:
drsym <enter>
The user must next provide the name of the listing file, in this
case 'myfile'. DRSYM produces a file 'myfile.sym' that can be read
by DR6502. The user would next execute the DR6502 CONFIG program
(if a different memory configuration is to be used):
config <enter>
The user then provides a description of the memory elements in the
system. When the EPROM is input, the CONFIG program will as for the
name of the binary file, in this case 'myfile'. After the
configuration is complete, the CONFIG program will automatically
execute the DR6502 program. To run DR6502 with the same
configuration as before and with a binary file of the same name and
with a current or no symbol file then type:
dr6502 <enter>
The simulation begins.
page 3
The Simulation: What does DR6502 do when it runs?
-------------------------------------------------
The simulator constructs an exact memory map of your target
system with RAM, EPROM and VIA. The simulator then reads your .BIN
program file produced by TASM into the spaces allocated as EPROM.
(Note that the .BIN file is the form of your software that is ready
to be burned on an EPROM and installed on your target system so the
simulation will be exact.) The program then simulates the start up
and running of the processor. Several run time error conditions are
checked such as reads or writes to unallocated memory (not occupied
by a chip), attempted writes to ROM space, reads from RAM spaces
that were never set etc. Regular CPU crashes are recognized by the
occurrence of undefined opcodes.
When using the hardware simulator option, the RST, NMI, IRQ, SO
and RDY signals are monitored in the hardware and are obeyed by the
simulator. When used entirely in software, a simulated IRQ
frequency is available (Search /Option 'i'/).
The simulator is called a symbolic code simulator because it
will read a ??.SYM file for each EPROM present in your simulated
computer and will create a reverse symbol table. This table is then
used in the 'P' program option and 'D' assembly code to allow the
user to operate with the symbols that were used in the source code.
This makes viewing and editing the code (Option 'P') much easier.
With symbol information present, program outputs produced under
Option 'D' could be combined back into the original assembly code to
incorporate changes made during simulation sessions.
Other Benefits of the Hardware Simulator System
-----------------------------------------------
Once again, the hardware simulator is made up of two
components, an interface card and cable that plugs into an IBM
mother board slot and the DR6502 program. The copy of DR6502 given
out to all students is capable of operating in either hardware or
software mode. If a student wishes to construct a hardware
simulator card to use on their MS-DOS machine at home, the
schematics are given in the notes. In addition to simulating the
operation of the 6502 on the target board with DR6502, the interface
card can be used to run diagnostics.
The programs 'RAMTEST' and 'EPRMTEST' are used to test the RAM
and EPROM chips respectively. The program 'EEPROM' can be used with
the interface card to program electrically erasable, programmable
read only memories or EEPROMs of the XL2864A type or equivalent. By
installing the chip on your target computer board, plugging in the
interface cable to your 6502 processor socket and running one of the
above mentioned programs, all of these services are available
through the interface card.
Because students sometimes wish to test chips outside their
board or would like to test their VIA chips, an auxiliary board is
provided with ZIF (zero insertion force) sockets that uses a project
computer board as its base. The board has been specially wired to
allow testing of RAM, EPROM, and VIA or programming of EEPROMs.
page 4
2) Simulator Modes of Operations
================================
The program can run in one of four modes given by the
combinations of user output/no output and break point set/no break
point set. Each of the four modes gives a different amount of user
feedback and executes instructions at a different speed.
Screen Output:
When the simulator reports to the screen after every program
step, the execution is quite slow in comparison to the speed of a
6502. To speed up the execution of the program, the user has the
option to suppress screen printing thereby saving a great deal of
time. Note that any time screen output is selected, the history
file (DR_6502.HST) is updated as per its user selected output
option. When the screen output is suppressed, the history file is
not written to either. (Search /Option 'H'/)
Trace Controlled Screen Output:
The simulator has a control option (Search /Option 't'/) where
the screen output is enabled and disabled based on the position of
execution in the subroutine calling tree. This option is called the
trace option because it can be used to trace the execution of a
particular routine, performing all of the calculations in
subroutines without displaying them. The speed of execution of the
simulator is not effected whether operating under the trace mode or
not however as the trace option changes execution modes, the speed
changes accordingly.
Break Point Set:
If the 'processor' encounters the one user selected break point
address during any memory access (OpCode fetch, read, write etc) the
simulation will stop and await user prompting. If there is no break
point set then no check of addresses will be done. (Search /Option
'b'/)
Mode 1: Break Point and No Output
---------------------------------
The fastest execution occurs when a break point has been set
and no output is selected. In this mode the 'processor' blasts
along at maximum speed scanning for the ` key which indicates
switching back to full user output. Without user input the program
will run 'silently' until the breakpoint address is reached. At
maximum, the program is currently capable of simulating about 166
MCPS (machine cycles per second) or one second of 6502 CPU time in
about 1.67hr of XT (8Mhz) execution time which is 1/6000th real
speed. With delay loops disabled, this mode can move very rapidly
though the program, executing about one page of assembly source code
per second. Since most every computer owned by students is many
times faster than an XT, the simulation will be that much faster on
their machine at home. If the break point address is reached, the
program will switch to Mode 4: Stopped Mode.
page 5
Mode 2: No Output, No Break Point
---------------------------------
The program still scans for the ` key because with no break
point this is the only means of returning the program to full output
mode. Since the program will run indefinitely in this mode, the
user needs to know at what stage the program is so that it may be
stopped near points of interest. The program prints the current
program counter value to the screen after each program step to let
the user know where the program is. This mode runs at about 118
MCPS, that is 70% of the speed of mode 1.
Mode 3: Full Output
-------------------
In this mode the program prints the values of all registers
after every program step. If there is a break point set then the
current fetch and program addresses will be compared to the break
point address at each program step. If the program reaches the
break point address it will go into Mode 4: Stopped Mode. Running
with full output with or without a breakpoint is very slow but still
faster than the average human is able to absorb the information
flipping past on the screen. For this reason the program builds a
DR_6502.HST history file on disk that records any program steps that
are displayed on the screen. In this mode the simulator executes
about 16 MCPS or about 1/10th the speed of mode 1 including all disk
and screen output. In this mode the program is scanning for user
input. To transfer to modes 1 or 2 press the ` key. To stop the
execution (go to Mode 4: Stopped Mode) press the 's' key (stands
for 'STOP').
Mode 4: Stopped Mode
--------------------
In this mode the program does not execute program steps but
waits for user input. To go back to each of the other modes from
mode 4, the user must input:
Mode 1: Enter a [new] break point address. Press the ` key.
Mode 2: Press the ` key.
Mode 3: Press the 'g' key (stands for GO)
To remain in stopped mode but advance by one program step, the
user can press the 's' key (stands for STEP). The other command
options available are explained in the next section.
page 6
3) Stopped Mode Simulator Command Options
=========================================
Since there are several avenues open to the user under the
stopped mode, no command prompt is displayed but the program will
react to keystrokes. The following is a list of the keystrokes and
the commands they initiate. The more complete description of what
each of the commands does is given in below. The reader can use a
word search or find option searching for /Option 'x'/ where x is the
keystroke to be searched.
Key | Function
====================================================================
|
b | Set the break point address
|
t | Trace on, Full screen output for this level subroutine
| only. Screen output is disabled upon JSR and is
| re-enabled after the matching RTS is executed.
|
T | Trace off
|
d | Dump memory data to a disk file in hex, TASM or block
| format
|
R | Read a disk data file in block format into memory
|
* D | Dump Disassembled Program to a Disk file in TASM format
|
p | Poke values into memory (good for simulating I/O, sensors)
|
* P | (Re)Program: Disassembles a Page of Program Memory and
| Offers the following sub-menu
|
| Key Function
| ==========================================================
| u move Up a line in the program
| d move Down a line in the program
| c Change the code - begin reprogramming in assembly
| code
| s Save current page
| r Reread current page discarding any changes
| + read and disassemble the next memory page of the
| program
| p read and disassemble a different Page
| m Make space for new assembly code to be inserted
| i Symbol information
| a Assign a Symbol
| l Label current line with a symbol
| b toggle display of Branch line labels
| n modify Notepad
| q Quit Program module - do not save the current page
|
|
page 7
m | Monitor an address (variable)
|
r | Change the contents of the processor Registers including
| the flags
|
v | View memory in hex dump format to the screen
|
n | Display and edit the notepad
|
l | List a text file to the screen - copy to notepad
| f - find text
| ESC - quit
|
h | History, display the short history that is maintained in
| memory
|
H | Change the history file and short history format
|
! | RESET the processor - all memory remains
|
i | Set interrupt frequency (Available only in software
| simulation mode)
|
e | End the simulation - Check DR_6502.HST for a log of that
| run
|
? | HELP - List the Keystrokes available to the user
|
====================================================================
* Segments contained in the second overlay. Upon initiating the
command the simulator will stop for a few moments to transfer in
'OVERLAY1.EXE'. These segments of the program utilize the symbol
information if present to enhance their operation. Please see
section 5) DRSYM and the Symbolic Debugging.
page 8
4) After The CRASH: Simulator Command Options
=============================================
After the simulator has flagged some condition that would lead
to a malfunction of a real 6502 system, the mode of operations
changes to the post crash analysis. The user has many option
available to analyze memory and processor status to discover where
things went wrong. The user also has the option to direct the
simulator to return to normal operations after some adjustments to
registers or data has been made. The following is a list of
commands available in the post crash analysis.
Key | Function
====================================================================
|
d | Dump memory data to a disk file in hex, TASM or block
| format
|
* D | Dump Disassembled Program to a Disk file in TASM format
|
p | Poke values into memory (good for simulating I/O, sensors)
|
* P | (Re)Program: Disassembles a Page of Program Memory and
| Offers the following sub-menu
|
| Key Function
| ==========================================================
| u move Up a line in the program
| d move Down a line in the program
| c Change the code - begin reprogramming in assembly
| code
| s Save current page
| r Reread current page discarding any changes
| + read and disassemble the next memory page of the
| program
| p read and disassemble a different Page
| m Make space for new assembly code to be inserted
| i Symbol information
| a Assign a Symbol
| l Label current line with a symbol
| b toggle display of Branch line labels
| n modify Notepad
| q Quit Program module - do not save the current page
|
|
r | Change the contents of the processor Registers including
| the flags
|
v | View memory in hex dump format to the screen
|
n | Display and edit the notepad
|
h | History, display the short history that is maintained in
| memory
|
page 9
H | Change the history file and short history format
|
! | RESET the processor - all memory remains
|
e | End the simulation - Check DR_6502.HST for a log of that
| run
|
? | HELP - List the Keystrokes available to the user
|
j | Jump Start the simulation - Direct the simulator to resume
|
====================================================================
* Segments contained in the second overlay. Upon initiating the
command the simulator will stop for a few moments to transfer in
'OVERLAY1.EXE'. These segments of the program utilize the symbol
information if present to enhance their operation. Please see
section 5) DRSYM and the Symbolic Debugging.
page 10
5) DRSYM and Debugging with the Symbolic Assembler/Disassembler
================================================================
DRSYM is a very short program that reads the symbol table
printed in ASC II at the end of the TASM list file and turns it into
a packed binary file for input into DR6502. DRSYM also excludes
from the list of symbols it produces, any symbols that appear
anywhere in the assembly code as constant arguments in the format
'#symbol'. The reasons for this will be explained later. If
another assembler is used other than TASM, a different DRSYM program
will need to be programmed. For this reason both the BASIC source
code and compiled code for DRSYM have been provided so that the user
may alter the program to read the list file from their favorite
assembler.
With the symbol information and the machine code the simulator
is able to recreate your assembly code fairly closely. The two
program modules that use this ability are the 'D' dump assembly code
to disk file and the 'P' (re)program assembly code modules.
'D' Dump Assembly Code Option
-----------------------------
The 'D' dump code option is quite straight forward. The
simulator looks at the section of memory to be disassembled and
dumped to the disk and inserts labels whenever it finds a match
between an address reference and a label value.
Constants
Labels are not substituted in the case of constant references
since there may be times when #$01 is used as the 'number 1', 'bit
zero set' or 'true' each with a different label. It would be
impossible for the simulator to determine which usage of the #$01
was intended in a particular piece of code. Since constants are
never substituted for, there is no need for constant labels to
appear in the symbol table. For this reason, DRSYM does not record
constants labels in the symbol table in the .SYM file.
Address with No Symbol
References to addresses that do not have a corresponding label
but are only a few bytes offset from a label will be recorded as
'label+offset' assuming a multibyte storage data structure. For
example, if 'Register_0' where assigned the value of $00 in the
source assembly code and no label were assigned to the address
$01, it is very likely that references to the address $01 would
actually be written in the code as 'Register_0 + 1' where
Register_0 is in this case a multibyte piece of data. If
contents of address $01 had absolutely nothing to do with the
contents of address $00 then, as dictated by good programming
style, $01 should have been assigned a label that explained its
purpose such as 'Register_1' or 'Temp'.
Though these rules may not seem to make sense when stated,
experimentation has found, on average, this set of rules produces
code that is closest to the original assembly source code. It is
very possible that the code reproduced by DR6502 will be identical
page 11
to the original source code with the omission of the comments. The
dump module is not interactive, the output of the symbolic
disassembly goes directly to the user specified disk filename. The
output of the dump option is easily incorporated into the original
source code to reflect reprogramming done in the 'P' (re)program
code option.
'P' (re)Program Code Option
---------------------------
The 'P' (re)program code option is an interactive symbolic
assembler/disassembler based on a machine language page of assembly
code. As with the 'D' dump option the 'P' option disassembles
starting at a user specified memory address inserting address labels
in the same manner as described above. The disassembled code is
displayed on the screen and the user can move up and down through
the page. The user can inquire about label information, assign a
new label or label the current memory address indicated by the line
the cursor is currently on. The user can modify the code and use
labels to specify any arguments including constant arguments (like
#True for #$01).
**** In fact the user need not start with any real code at all! ****
By assembling a file with one instruction, and the reset vector, the
user can start the simulator with no actual program present. The
'P' option could be used as an interactive, line by line assembler,
inputting labels as necessary developing code on the fly. Though
this is definitely not a good programming practice, it is very
useful if the user just wants to try something out, preferably that
will code out to less than 256 bytes of machine code or about 100
lines of assembly code. After the code has been programmed or
reprogrammed in the case of repairing a bug, the page must be saved
back to the memory of the simulated 6502.
Using the 'P' option, it is possible to work on your code in
the simulator at a near source code level provided symbol
information is provided. It is convenient and wise to use the 'D'
option to record to disk, for later reference, any changes made to a
section of the assembly code. Search /Option 'D'/ or /Option 'P'/
for specific information on how each option is used.
page 12
6) Explanation of Commands
===========================
Option 'b'
----------
Often the user would like the code to run to a certain point
and then stop. DR6502 allows the user to set a break point address
and whenever that address is used in a memory fetch of any sort,
including data, the simulator will stop and display the current
status of the simulated processor. This can be used to make the
program execute to a certain address by specifying the code address
you wish the program to stop at. The user can monitor the data
traffic to a VIA port by setting the break point to be the address
of the VIA port. In this case whenever a read or a write is done to
the port the simulator would stop and display the status.
Option 't' and Option 'T'
-------------------------
The 't' trace option modifies the screen output of the
simulator. The 'b' option allows the user to execute until a
certain address. Often, the user wants to execute a routine that
calls a number of subroutines. In this case the user may only be
interested in monitoring the execution of the program when it is in
the high level routine and not when it jumps into the lower level
subroutines. When the trace option is initialed at a particular
point in the subroutine call tree, DR6502 automatically switches to
no output mode (as initiated by the ' option) when executing
subroutines at nesting levels lower and switches back to full output
mode for subroutines of a equal or higher nesting level. This
allows the user to view only the higher level logic. The 'T' cancel
trace option, cancels the current trace mode.
Option 'm'
----------
The 'm' monitor a variable option allows the user to constantly
monitor the contents of a memory location. The value is displayed
in the status area next to the 6502 register values. This option
can be used to monitor a memory location that is used by the code as
a variable or it can be used to monitor in a memory location
corresponding to a VIA port. The user is given the option of
selecting a two byte display where the memory location specified and
the one following are interpreted as a 16 bit variable.
Option 'r'
----------
The 'r' modify registers option allows the user to modify the
processor .A, .X, .Y, .SP, .PC and .R registers. This option can be
used to correct for data or stack errors recognized in the program.
As the user is testing their individual subroutines, they may wish
to place the break point at the RTS, set data register initial
values and then set the program counter to begin the routine.
page 13
Option 'j'
----------
Presumably if the crash was not too bad and a little adjustment
of the registers will fix it (including possibly the program
counter) then the program will allow you to attempt to jump-start
the simulation again. This may be attempted as many times as the
user wishes.
***** WARNING ***** An infinite loop is NOT a crash if it is
composed of valid 6502 instructions, so be careful.
Option '!'
----------
The '!' reset option performs the same function on the
simulator as the reset button on the target microprocessor board.
The user is given the option of changing the type of 6502 processor
simulated.
Option 'h'
----------
The 'h' history option displays a short history of the last 9
instructions that the processor has executed. The user will
probably find this most helpful after the simulation has stopped at
a break point to discover by what manner it came to arrive at the
break point.
Option 'H' and the History File
-------------------------------
As stated earlier, the simulator writes to a history file
whenever full screen output is selected. The format of the file can
be controlled by the 'H' history file mode option. The first choice
is full output including disassembled code, all registers, program
counter before and after and the monitored variable address and
value (if selected) at every program step. The second choice is
every line output with the disassembled code only. The last option
is nesting output that writes to the history file only on the
occurrence of JSR, RTS, BRK, RTI and the hardware interrupt.
The first choice is most useful if extensive checking of the
flow of data through the registers is desired. The disadvantage of
full output mode is that it requires a lot of disk storage space for
the DR_6502.HST file. The second mode is best for simple tracing of
the program execution. This mode requires less disk space yet still
provides enough information to help debug the program. The third
option allows the user to check that subroutines are nested properly
and called when expected. This mode saves a great deal on disk
space (and runs faster too) by cutting out a lot of the unnecessary
information not required for high level debugging.
page 14
Sample output from mode 1:
Addr Op Args Mn Addr Mode A X Y SP PC PC NV BDIZC Variable
-----------------------------------------------------------------------------
F001 A2 FF LDX #const (2) 00 FF 00 00 F001=>F003 10100100 0080=#$????
F003 9A TXS (2) 00 FF 00 FF F003=>F004 10100100 0080=#$????
F004 58 CLI (2) 00 FF 00 FF F004=>F005 10100000 0080=#$????
NOP Cruise $F005-$F009
F009 EA NOP (10) 00 FF 00 FF F009=>F00A 10100000 0080=#$????
F00A A9 FF LDA #const (2) FF FF 00 FF F00A=>F00C 10100000 0080=#$????
F00C 8D 00 02 STA addr (4) FF FF 00 FF F00C=>F00F 10100000 0080=#$????
F00F A9 02 LDA #const (2) 02 FF 00 FF F00F=>F011 00100000 0080=#$????
F011 85 81 STA zpage (3) 02 FF 00 FF F011=>F013 00100000 0080=#$????
F013 A9 00 LDA #const (2) 00 FF 00 FF F013=>F015 00100010 0080=#$????
F015 85 80 STA zpage (3) 00 FF 00 FF F015=>F017 00100010 0080=#$0200
F017 A9 55 LDA #const (2) 55 FF 00 FF F017=>F019 00100000 0080=#$0200
F019 8D 01 02 STA addr (4) 55 FF 00 FF F019=>F01C 00100000 0080=#$0200
F01C A9 01 LDA #const (2) 01 FF 00 FF F01C=>F01E 00100000 0080=#$0200
-----------------------------------------------------------------------------
Sample output from mode 2: (Note: this is the default mode on start up)
Addr Op Args Mn Addr Mode
---------------------------------------------------------------------------
F001 A2 FF LDX #const (2)
F003 9A TXS (2)
F004 58 CLI (2)
NOP Cruise $F005-$F009
F009 EA NOP (10)
F00A A9 FF LDA #const (2)
---------------------------------------------------------------------------
Sample output from mode 3:
Addr Op Args Mn
---------------------------------------------------------------------------
F020 20 00 F8 JSR dest (6)
F812 60 RTS (6)
---------------------------------------------------------------------------
Other History File Entries
--------------------------
Certain conditions including errors and warnings produce
notations in the history file. The following are several such
example entries.
page 15
Sample RESET Entry:
Each time the simulator is RESET the following appears in the
history file:
--------------------------------------------------------------------------
RESET ====> $FFFC
Reset Vector = $F000
F000 78 SEI (2) **** Note this depends on your first instruction
--------------------------------------------------------------------------
Sample Stopped Mode Entry
Each time the user presses the 's' key whether to stop
execution or to step execution by one step the value of all
registers is written to the history file.
-------------------------------------------------------------------------
Time=000000.000042 million cycles
Registers:
Acc=$01
Xreg=$FF
Yreg=$00
SP=$00
PC=$F01E
N V 1 B D I Z C
0 0 1 0 0 0 0 0
------------------------------------------------------------------------
Sample NOP Special Execution Entry
Often a program will contain large areas that contain nothing
but NOP no operation instructions. Since these instructions do not
modify memory, registers or program flow, they are given a special
notation in the history file to save space.
-----------------------------------------------------------------------
NOP Cruise $F005-$F009
F009 EA NOP (10) 00 FF 00 FF F009=>F00A 10100000 0080=#$????
-----------------------------------------------------------------------
Option 'i'
----------
In software simulation mode, there is no target computer to
provide NMI or IRQ signals. The simulator provides an option where
one interrupt signal can be simulated at a user defined frequency
(period given in clock cycles). This 'signal' can be blocked by the
interrupt flag in the processor status register. This 'signal' can
be blocked by the interrupt flag in the processor status register
and uses the IRQ jump vector so it is a close simulation of the IRQ
function of the processor.
page 16
Option 'e'
----------
The 'e' end option allows the user to end the simulation
session. The history file maintained on the disk is closed and the
simulator returns the use stopped or crashed mode.
The 'n' Notepad Option
----------------------
A minor deficiency in the DR6502 program was the necessity for
the user to constantly be making note of addresses so that they may
be correctly input to another option of the program etc. Such minor
note taking has been taken care of by the 'n' option where the user
is given four lines at the top of the screen (used for errors and
warnings only) to make notes of any kind. This area of the screen
is not erased after the user exits the notepad option and may stay
for quite a while. The contents of the note pad can always be
called up again if they are erased.
The 'l' List Text File Option
-----------------------------
Sometimes the user would like to check a text file for
information necessary to the debugging of the code under testing.
Commonly the user would like check the source or listing files from
the assembly code but this option allows any text file to be
examined including this documentation file for DR6502.
The reading of the text file is one way, forward only, with one
line read for each keystroke. The 'f' key in this mode invokes a
find or search function. The <ESC> ends this option. On exiting
this option the user is allowed the option to copy the portion of
the file displayed into the notepad so that it may be edited and
redisplayed. Note: there is no facility to copy the contents of the
notepad back to the file or to a different file so this cannot be
used for file editing.
Option 'v'
----------
The 'v' view memory option allows the user to display portions
of the 6502 virtual memory to the screen. With this option the user
can check the data values at any point in the execution of the
program code. The memory is listed beginning at a user supplied
address and then the user has the option of paging up and down
through the memory using the 'u' and 'd' keys.
Option 'd'
----------
The 'd' dump data option is conceptually equivalent to the 'v'
view option. The dump option allows the user to dump the contents
the 6502 virtual memory to a disk file in hex format for later
inspection or merging into a TASM source file. This allows the user
to take data generated by 6502 commands and incorporate it into the
source code. The 'd' option dumps a section of memory to a disk
page 17
file in one of two formats, either in hex format:
F000 A9 00 8D 00 02 CD ........
for easy (?) interpretation later or in 'TASM' format:
.ORG $F000
.BYTE $A9,$00,$8D,$00,$02,$CD,....
for easy merging with the program source code to make it a data
table. (see Appendix A)
The user may also record the data in a 'block' format in the
data file. The block format is useful for recording memory values
to be read back into memory later using the 'R' option. The format
of a 'block' file is as follows:
4096
0, 1, 2, 3, 4, 5, 6, 7
8, 9, 10, 11, 12, 13, 14, 15
-1, 0, 0, 0, 0, 0, 0, 0
The first number '4096' corresponds to the address in memory,
in this case $1000 at the beginning of the data block. The numbers
that follow, in rows of 8, are the values of the memory locations
sequentially following the beginning address of the data block. The
last line must begin with a -1 followed by 7 other numbers. All
numbers (except the -1) must be in the range 0-255.
Option 'R'
----------
The 'R' read data option inputs data from disk files into the
6502 ram memory in a block format (see Option 'd', 'block' output as
described above). The data file may be produced by DR6502 by the
'd' option or may be created by a user with a text editor. See the
'd' option above for details on the format.
Option 'p'
----------
The 'p' poke option allows the user to directly write to RAM
spaces within the 6502 virtual memory map. The user supplies a
start address and fills in the values in that and successive
locations by separating the figures with spaces. The user can
prefix the data with '