informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/programming/qikstart.txt

438 lines
17 KiB
Plaintext
Raw Normal View History

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