informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
master
textfiles/programming/dr6502.txt
T
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

2075 lines
75 KiB
Plaintext
Raw Permalink Blame History

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 '$' or '%' to indicate hexidecimal format or
binary format respectively. If no prefix is included, the data is
assumed to be decimal. Once a prefix is attached to the first
figure, all other figures input on that line are assumed to be in
the same format and no further prefixes are required. For example,
typing:
$7f 6a f2 00 37
would place $7F in the specified memory location and $F2, $00 and
page 18
$37 int and no further prefixes are required. For example, typing:
$7f 6a f2 00 37
would place $7F in the specified memory location and $F2, $00 and
$37 in the next 3 memory locations.
Option 'D'
----------
The 'D' dump program option is used to dump a disassembled copy
of the program in a user specified memory range to disk. If symbol
information is read into DR6502 then the disassembled listing will
contain symbolic representations for any address references in
arguments. This allows the user to make changes in the code
permanent. (See Appendix B: Merging with EDIT/Blackbeard to
recognize the possibilities here)
Option 'P'
----------
The 'P' (re)program option reads, disassembles and displays 256
bytes or one page of program code starting at a user selected
address. The user may then move a cursor '=>' up and down ('u' and
'd') line by line through the disassembled page. The user may quit
the 'P' (re)program option with the 'q' key. The '+' key causes the
simulator to read the Next page of assembly code. If the user would
like to look at a different part of the code, the 'p' causes the
simulator to read a new page of code starting at a user specified
address. Using these commands and the 'u' and 'd' commands this is
similar to a 'view code' mode however there are other subcommand
options that allow the user to alter the program at the assembly
language level.
The 'c' change suboption allows the user to input lines of
assembly code as opcodes and operands. Note that labels and macros
are not allowed since this is a line by line assembly process. Be
warned that the change suboption overwrites the bytes of code that
were in the locations prior to changing. If the change requires
more than a simple substitution or if the user is not certain that
the opcode alignment will be preserved after the change then the
make space option (described below) should be used first.
All editing of the code is done in a buffer so that if
mistakes are made in changes to the code, the actual 6502 memory map
can be read again to retrieve the original program. The 's' save
subcommand saves the current page of assembly code back into the
6502 virtual memory. This does not make the change permanent (to
the binary file) but will remain for the rest of the session with
the simulator. If the user would like to make program changes made
in the simulator permanent then consult the 'D' option of the
Stopped Mode commands.
If the user has made changes to the program in the buffer and
would like to discard them and reread the program from the 6502
page 19
virtual memory then the 'r' reread option is available. This will
discard any changes that may have been made in 'c' change operations
but will not discard changes that have been saved with the 's' save
option. If a virgin copy of the program is required then the user
must exit the simulator and start over so that the .BIN file can be
reread.
The simulator is capable of reading a file of symbol
information if one is produced using DRSYM. Whether a file has been
input or not the user can 'a' assign values to new symbols or 'l'
label the current memory address with a symbol (as with branch
labels). The user can search the list of symbols for 'i'
information, either the symbol assigned to an address or the address
represented by an symbol. Users may prefer to see or not to see the
branch line labels in the assembly code and these can be toggled on
and off by the 'b' option.
The user is able to make notes in the notepad with the 'n'
suboption of the 'P' option. This is the same notepad as is
accessed from the stopped status screen and is very useful for
making note of address, labels or diagnostic states.
When the user has found that an error has been made and some
code has been omitted, the 'c' change suboption is not sufficient.
The user must first open up a space in the program for the omitted
code to be inserted. The 'm' make space option does just this.
Here is a graphical representation of the 'make space' process
Program Start Addr > ============= =============
| | | |
| | | |
| A | | A |
| | | |
Cut ____|___________| |___________|
Here | | | |
| | | NOP Filler|
| B | Slide down ____|___________|
| | to here | |
| | | |
Program End Addr > ============= | B |
| | | |
| | | |
=============
............. End of Eprom .............
Process in Brief:
1) Program sections (A+B) are searched for address references to the
B section (JMPs, JSRs, Branches, Data access like LDA, STA etc).
The references are adjusted to reflect the relocation of the B
section of the program.
Two possible error conditions can arise during this
adjustment. Relative branches have a maximum length of 128
page 20
bytes. If a relative branch forward or backward crosses the cut
line and the added length of the branch due to the inserted
section exceeds the maximum length of a branch then an error is
counted and the branch is recorded as Bxx $FE. This will result
in an endless loop if the branch is taken but will also be easier
to find if you have to change it. Absolute addresses must fall
into the range of $0000-$FFFF. If the user has miscalculated and
tries to make so much space that the end of the B section of the
code is pushed off the end of the EPROM space (past $FFFF) then
another error will occur. If an absolute address plus the offset
of the move exceeds $FFFF then these are counted as errors and the
address is recorded as $0000. This would happen for references to
the part of B that is pushed off the end of the EPROM.
If any symbol information has been input into DR6502, either
with a .SYM file at the beginning of the session of during the
session with the 'a' assign symbol or 'l' label current address
commands, then these symbols are adjusted as well. The code will
automatically adjust all address labels that fall into the range
of code being moved.
Since labels used to represent constants (as opposed to those
used to represent addresses) are not present in the symbol table
as created by DRSYM, the DR6502 system attempts to shield the user
from the following problem. In the rare instance that the user
has used the 'a' assign symbol to assign a symbol used as a
constant AND has assembly code on the zero page AND uses the 'm'
make space option to move it, the following can be a problem.
There is the possibility that constant symbols may be confused for
address labels. If for instance the code being moved was in the
range $0060-$0090 and a constant label like 'Bit_7_set = $80' is
assigned by the user during the simulator session, then DR6502
will mistakenly adjust this label's value interpreting it as an
address. This has NO EFFECT on the actual code since in the
memory of the 6502, TASM has already removed the symbols from the
machine code. This also has NO EFFECT on the disassembled outputs
produced by DR6502 in the 'D' or 'P' options since constant
arguments are never substituted for. In the 'D' option however,
at the beginning of the file produced, DR6502 writes out the
values of all the symbols in the form of assembly language
assignment statements. (This allows the 'D' dumped code to be
reassembled directly if the user desires.) In the list of
assignments the label 'Bit_7_set = ...' will have an adjusted
address.
2) The slide is performed, regardless of any errors that were
encountered. The simulator was programmed assuming the user knows
what they are doing, allowing users who know what they are doing
to do some very unusual things. If one of the errors mentioned
above occurs and you were not anticipating it then it may be best
to end the session and start again with a virgin copy of the
binary code.
3) The space opened up is then filled with NOP instructions. Since
NOP instructions are one byte long, they can be replaced in the
'c' change option in reprogramming the code without worrying about
the opcode alignment. The simulator is optimized to execute a
memory space filled with NOP instructions very quickly so the user
need not worry about opening up a little more space than is
required by the code to be inserted.
page 21
The 'm' make space subcommand requires the user to input the
first and last program space addresses to define the space A+B. The
address of the first opcode of section B is input to define the
position of the cut. The new address of the first opcode of section
B is input to define the offset of the relocation. Spaces can only
be created by this method. If a data table is present then care
must be taken that it has been handled in one of the ways as
described below.
Address references are CORRECTED for the new location of the
relocated part of the code but ONLY within a user specified
'program' area. Herein lies another problem. A program is a thin
line of opcode alignment; shift by one byte and a program starts
looking like a random stream of bytes. (See Appendix A for an
explanation/definition of opcode alignment) Given a valid program
opcode address as a starting point, a program can be traced and
address references to the area of relocated code can be adjusted.
If the program encounters a 'data' space half way through the
'program' space it is not trivial for the program to determine where
the data space ends and the program space resumes since op-code
misalignment can make programs look like data and coincidental data
may appear to be a program. As a result, if this relocate option of
DR6502 is to be used one of three arrangements must be used. NOTE:
the described options are only necessary if DATA (.BYTE or .WORD)
directives have been included in the eprom.
One option is to put user data tables that are to be burned
into the eprom at the beginning of the eprom before the program
code. In this case, the user specified 'program' space defined for
the purposes of address reference adjustments would be specified
from after the data table to the end of the program. (Note NOT the
end of the eprom! If the user hopes to create a blank space in the
program space then the end of the program cannot be specified as the
last address of the eprom or the memory shift will result in
'spillage' off the high end of the eprom.)
A second option is to put the data directly after the program.
In this case two things are necessary. First the data must be
defined as part of the program space so that it is relocated along
with the code instead of being overwritten. This will also make
sure that address references to the data table will be corrected.
At least one non-opcode byte must appear between the program and the
data table so that when DR6502 encounters this byte it will know a
data table has started and it will not attempt to interpret any
bytes that follow as opcodes or operands. Any non-opcode byte would
do just fine.
A third option is to put the data table at the very highest
address of the eprom, leaving a space between the end of the program
and the beginning of the data. In this case when defining the
'program' section, do not include the data. The relocated program
will move closer to the data when slid toward higher memory to make
room for more program lines.
page 22
7) Extended Instruction Set for the 65C02 and Rockwell R65C02
=============================================================
With the development of the AER 201S computer board, which uses
the 65C02, it became more necessary for DR6502 to handle the
extended CMOS instruction set. Since the R65C02 is commonly
available, the specialty Rockwell instructions may also be
required. The following instructions were therefore added:
Branch Bit Reset (R65C02):
BBR0 zpage,rel ; BBR1, BBR2, BBR3, BBR4, BBR5, BBR6, BBR7
Branch Bit Set (R65C02):
BBS0 zpage,rel ; BBS1, BBS2, BBS3, BBS4, BBS5, BBS6, BBS7
BRanch Always (65C02):
BRA rel
PusH/PulL X and Y (65C02):
PHX, PHY, PLX, PLY
Reset memory bit (R65C02):
RMB0 zpage ; RMB1, RMB2, RMB3, RMB4, RMB5, RMB6, RMB7
Set Memory Bit (R65C02):
SMB0 zpage ; SMB1, SMB2, SMB3, SMB4, SMB5, SMB6, SMB7
STore #$00 Zero into a memory location (65C02):
STZ address mode
Test and Reset Bits (65C02):
TRB address mode
Test and Set Bits (65C02):
TSB address mode
Note that no accurate number of clock cycles durations were
available for the R65C02 instructions so estimates were used based
on other 6502 instructions.
The simple indirect (zpage) address mode was also added for memory
fetches as per the 65C02 standard. The special address/argument
structure of the BBSx and BBRx of zpage,rel is also supported.
page 23
8) Differences Between DR6502 and the R6502, 65C02 and R65C02
=============================================================
Reference 3, Hendrix, details some anomalies in the operation
of the 6502 in Chapter 6 'Quirks, Bugs and Other Oddities of the
6502' which will be mentioned shortly. The simulator was not
programmed intentionally to imitate any of these problems in the
6502.
When using the add or subtract instructions in decimal mode on
the NMOS 6502, the Negative flag, Overflow flag and Zero flags are
not valid. On the 65C02 they are valid however the instructions
require one more clock cycle. In the simulator they are valid,
regardless of 6502 version simulated and the execution clock cycles
used are correct for the type of processor selected. If the
simulator is used to simulate an NMOS 6502 using the add and
subtract in decimal mode and makes use of the N, V or Z flags, the
simulation will not match the real (errant) execution of the NMOS
6502.
When using the indirect jump with a the address of a page (ie:
ending with $FF), an NMOS 6502 does not fetch the high byte of the
jump vector from the first byte of the next page but incorrectly
from the first byte of the current page. In NMOS 6502 mode, the
simulator flags JMP ($xxFF) as an error because on a 6502 it leads
to an incorrect jump. It is assumed that no program is designed to
exploit this error. The 65C02 does the jump correctly requiring an
addition clock cycle as does the simulator in 65C02 and R65C02 mode.
The unimplemented opcodes on the NMOS 6502 do unpredictable
things, sometimes crashing the CPU. The unimplemented opcodes on
the 65C02 and R65C02 are taken as NOP instructions. All
unimplemented NMOS 6502, 65C02 and R65C02 instructions are
interpreted as crash codes by the simulator since it is assumed a
user will never use an invalid code in the intended program.
The 6502 has no such thing as an idle bus cycle. In all cycles
there must be either a read from or a write to memory. The NMOS
6502, 65C02 and R65C02 all perform an extraneous read when executing
a absolute indexed addressing mode. The NMOS 6502 reads the next
byte after the instruction's argument, sometimes causing an error
with I/O devices that are sensitive to having their port memory
location read. The 65C02 and R65C02 both read the last byte of the
present instruction with less chance of such an error. The
simulator does not perform any extraneous reads.
The NMOS 6502 does not modify the decimal mode flag in the
processor status register in a reset operation or an interrupt. The
65C02 and R65C02 does clear the decimal mode flag in these two
cases. The simulator clears the decimal flag for all resets
regardless of the processor chosen. The simulator clears the
decimal flag on interrupts only in the case of 65C02 and R65C02
processors.
The NMOS 6502 requires 7 machine cycles to perform an absolute
indexed read/modify/write operator type instruction such as INC, ASL
or ROR. The 65C02 and R65C02 requires only 6 cycles to do the same
instructions in that particular addressing mode. The simulator uses
the correct number of cycles in each case.
The NMOS 6502 does not save any information on receiving a
reset signal. The 65C02 and R65C02 saves information on reset
consistent with an interrupt signal. The simulator does not save
page 24
any information on reset regardless of which processor it is
emulating.
In read/modify/write operator instructions such as DEC, LSR or
ROL there is an 'idle' bus cycle during the modify operation. As
mentioned above there is no such thing as an idle cycle for the
6502, either a read or a write must be performed. In the case of
these type of instructions, either a read or a write is performed in
the modify cycle to the address that will be written to on the
following cycle. Once again, unnecessary reads or writes can cause
problems with peripheral ports. The simulator does not do the
extraneous read or write.
Summary
-------
All of the above cases where the simulator deviates from the
processors, the instances are rare or the true behaviour is
undesirable. Any other deviations from the simulation of the actual
behaviour of the processor chosen is an error in the simulator.
Though not many such errors are likely to exist in the program,
there are undoubtedly a few left. Such errors will be fixed as soon
as they are identified by a user or a user supplies a minimum length
program (5-10 lines) and the simulator commands that will cause the
error every time.
page 25
9) DR 6502 Support Files
========================
List of Files Necessary to the Operation of the Simulator
---------------------------------------------------------
DR6502.EXE - Main executable code of the simulator
OVERLAY1.EXE - Second module of the simulator program
CONFIG.EXE - Creates Memory Map 'CONFIG' files for your target
BLANK.BAS - A file used to initialize the 6502 virtual memory
CINST.SET - 6502, 65C02 and R65C02 Instruction sets
DRSYM.EXE - Symbol table preparation program
DRSYM.BAS - The BASIC source code for DRSYM.EXE
MM.COM - Utility to display memory allocation
MARK.COM - A memory resident utility whose purpose is to
mark a point in memory
RELEASE.COM - A memory utility used to release all memory
resident programs added after the last mark
in memory
page 26
10) References
==============
1) Commodore 64 Reference Manual, Chapter 5: Machine Language,
pp209-259
2) The Transactor, Volume 4, Issue 05, pp52-53 (Reprinted in your
handouts)
3) Steven P. Hendrix, The 6502, 65C02 and 65816 Handbook, Weber
Systems Inc., Cleveland, Ohio, 1986, pp221-227
page 27
Appendix A: OpCode Alignment
============================
Note that the 65C02 will not necessarily have the same problems
as a 6502 with opcode alignment, it will have worse problems
actually. Please read on and the differences will be explained.
So you aren't quite clear on what exactly I mean by opcode
alignment. Consider this question: How many groves are there in the
average phonograph record? The answer is one (or maybe two - one on
each side). This is a very unique condition if you think about it:
Put the needle down anywhere and the record will always play the
same series of songs. A few years back there was at least one
novelty record made where there were two groves, two possible series
of songs depending on the original placement of the needle on the
record. This record is conceptually similar to an assembly program,
where the songs represent the instructions in the program. The
series of songs played depends on the starting point on the record,
whether grove one or two is chosen. There are only two possible
'programs' available to the listener. Only the radial starting
point in the record determines what portion of two 'programs' are
played. An assembly language program however is more closely
comparable to a Snakes and Ladders game with rich interconnections
than to the sequential nature of a recording.
I know, you are saying hold on now, I have only one program, I
used the assembler, where is this other program you are talking
about? Well you are absolutely right, you have only one program: in
assembly. In machine code it is just numbers in an EPROM. Try
looking at machine code even when you know what is supposed to be
there: the program is not obvious. The key point is recognizing
what bytes represent opcodes and what bytes represent operands. To
the human eye opcodes, 'pop' out from inspection. A9 - LDA; 8D -
STA; 20 - JSR Your brain sees these and recognizes the pattern. The
6502 is not blessed with this ability to 'see' what are opcodes and
what are not. All it knows is the next byte it fetches will be an
opcode, then the operands, then another opcode. Where you start
determines what the 6502 interprets as the first instruction and the
course of the program from then on. Using an assembler assures that
opcodes will be in the right spot at the right time and things will
go just fine, provided no .BYTE directives are placed in the middle
of a piece of code. The problem arises when the user starts hacking
around with a piece of software with a tool like DR6502. If the
code has an error or if the user messes up the program, an operand
may be fetched instead of an opcode and all of a sudden the 6502 is
executing a very different program.
So just how many of these alternate universe programs are there
in a given piece of machine code? Well, if you have 4k of code, if
we take 35-50% of those bytes to be opcodes and the rest operands
then there are a good 2000 possible alternate universes that your
6502 could fall into. There is some good news and some bad news.
These alternate programs are very unstable (and erratic) and they
usually do one of two things after a few opcode fetches. They
either crash (that's the good news, because you know you have a
problem) after fetching an bad opcode or they fall back in line with
the proper opcode alignment and things go back to normal. This is
very bad since you may have a 'mysterious' error that you have no
idea what is going on with. Now what are the probabilities for all
page 28
of this? Of all the 256 opcodes, about 151 correspond to valid
opcodes, about 35 crash the CPU outright and the other 70 or so are
weird combinations of incrementing and adding with strange flag
results. In a real 6502 system, the CPU has a (151+70)/256 chance
of continuing to execute. Upon the completion of each opcode there
is the chance that the proper opcode stream may be rejoined. The
chance therefore of an outright crash is low. The bottom line: this
is bad news.
Someone, in a stroke of genius, said lets make the 65C02
better. Lets make all of the undefined opcodes behave as NOP's.
The 65C02 can NEVER crash. After hopping into the wrong opcode
alignment, the 65C02 will execute a maximum of two undefined opcodes
in a row before rejoining the proper opcode alignment. The
difficulty is that the 65C02 has a great number more defined opcodes
so a 'strange' program will execute for a long time before hitting
an undefined opcode, executing a NOP and rejoining the proper opcode
stream (possibly). If you are operating DR6502 and have used only
regular 6502 instructions then you should use DR6502 in 6502 mode.
This will cause the simulator to object to a wider array of mistakes
and more quickly.
The overall landscape of a section of machine code if compared
to a record would have a great many possible paths threading near
the intended opcode path. The alternate paths would be short lived
in general and would most frequently rejoin the main path but would
occasionally dead end in a crash. The Snakes and Ladders
interpretation necessary when considering loops in the real code and
accidental branches, JMPs, RTS, JSR statements in the parallel codes
would not look very different since a quick count gives only
(8+1+2+2)=13 program counter modifying opcodes out of the 151 legal
codes. If the proportion is the same for the illegal 70 or so codes
then the chances of an accidental jump is only about 1 in 10. These
instances are catastrophes since the destination (by Murphy's Law)
is nearly always a pure data space where there is no opcode line to
be rejoined and the results can be very erratic.
In summary: How do you get off track and how to avoid it? The
easiest way is to push data into the stack in a subroutine and
forget to pull it off again before executing an RTS (frightfully
common error). Mishandling interrupts, etc could be a real problem
usually in the misbalance of the stack and return addresses. Doing
little tricks like using the address pushed on the stack after a JSR
in a calculation and returning the wrong number to the stack or
using calculated JMPs using a push and RTS method and messing up the
address etc would do it too. If you use DR6502 you could do it in
one careless p-poke command or not watching what you are doing while
using the P-program command. The best way to avoid the alignment
problem is knowing it exists and being very careful of the stack and
changes to the program.
An exercise: If you want to see what an alternate universe
program looks like, invoke the P-program function on DR6052 with a
program loaded. If your code starts at $E000 try giving DR6502 the
page start address of $E000+a random number that does not correspond
to an opcode address and observe the results. 105/256 opcodes will
show up as .BYTE directives which means you have no idea what a real
6502 would do. 70% of the time it will do something, with some
page 29
operands and lead to another opcode fetch. 30% of the time
(anything $x2 or $xF is usually a crash) it will lead to a crash.
DR6502 traps all undefined opcodes as errors and halts execution.
The 65C02 was improved to define all undefined opcopes to be
NOPs so that alternate program streams will never crash the system.
As pointed out before, the alternate program lines that rejoin the
main program line are more mysterious and dangerous than ones that
crash the computer outright. DR6502 still considers all
non-allocated 65C02 opcodes as crashes and halts the 'processor'.
This is done because in the actual program such codes should never
occur and when they do it is a sure sign that something is wrong.
page 30
Appendix B: Merging with EDIT/Blackbeard
========================================
You have probably found yourself reading this because you have
a section of 'invented' assembly that you made up to patch a bug
found while using DR6502 in one file and your original code in
another file. The merging process is a simple one:
1) edit the original file
2) ctrl-F2 to switch to window #2 (see Windows-Switch-window#2 in
ESC help menus)
3) ctrl-n to select a new file for window #2 (see Files-Newfile in
help) and enter the filename of the 'invented' section of code.
4) 'Copy' the desired section of the code from the 'invented' file
using f1 to mark the top of the range, f2 to mark the line after
the end of the range, f3 to copy this range into the paste
buffer. (transfer smaller blocks if the whole block is too large
for the paste buffer - shift f9 clears the paste buffer)
5) ctrl-f1 to switch back to window#1 where the original source code
is.
6) Cursor to the line that the range is to be inserted before and
press f7.
7) Make what ever other changes are necessary and
8) ctrl-z to save!

Reference in New Issue View Git Blame Copy Permalink