Simulation (Stage 1) -- Downloading and simulating task 1 |
The executable file "e1v3.out" generated from the source file e1v3.s is not optimal for "ease-of-use" with the SDS simulator. However, it is "useable" and we will optimize it later, when we know whether there are other problems to solve. These "fixes" will be valid for all future simulations.
You should now narrow down this WEB window so that you will be able to have both the WEB page and the SDS 68K single step simulator running side by side.
If you have not already done so, you should set the "start-up" directory" of the SDS simulator to lab1. Since the SDS simulator takes a number of start-up files from this "start-up" directory, it is important to set the directory path correctly (especially for the later laboratories).
Now activate the SDS 68K simulator. The simulator goes under different names depending on what SDS 68K simulator you downloaded. I shall assume you downloaded the SingleStep 68Ksim Windows' version. Under UNIX the simulator is called stepsim.
If you are using the Version 7.X SDS software you will find the appearance of the SDS toolkit screen equivalent but different. You'll have to use you imagination and translate the instructions into the Version 7.X equivalent until the "Labratory Companion" is updated.
We are currently researching into a technique that will allow the direct control of the SDS simulator from this WEB page. This is intended to help you over the initial learning curve on using the simulator. We have the approach working under UNIX but not yet under Windows.
If you prefer to have the SDS simulator occupy the full screen (I do) then make a hard copy of this, and the next few, HTML page. Refer to these pages for details while you use the simulator to run your code.
Note that with some printer devices and browsers (e.g. Netscape-2 browser printing to the Canon Bubble Jet BJC4000 running under Windows-95) the WEB links (underlined) do not print out. I believe this is a printer device problem as the same thing occurs on printing out with the MicroSoft FRONT-PAGE WEB page development kit. If you find this a problem, try downloading a more recent version of the printer device code.
FUTURE WARNING:- It will not be necessary during the next couple of WEB pages to have to modify the source files after simulation. However if at some future time you do try to modify your executable file from inside a DOS window while running the SDS simulator, you will find that you can't. The SDS simulator will block you from writing the new executable file to disk during the linking stage. There are ways of solving this problem. However the simplest approach when using the simulator in conjuction with a DOS window is to exit the SDS simulator toolkit before activating the linker.
When activating the SDS simulator, you will probably automatically get a Debug window appearing. If not, select the File command from the main window tool bar and activate the Debug option to make this window appear.
In the Debug
window there is a FILE button. Click FILE,
change to your working directory if necessary, select
"e1v3.out" and signal OK to the Open
(file) window.
Now signal OK to the Debug window. SDS now generates some important files to which we apply the WAIL principle (Worry About It Later).
We now get an Error window inside a Debug Status window with the message cannot find "START". This is associated with one of the "timesaving" features of the SDS software we have yet to activate. The code will still work, so just acknowledge OK in the Error window for the moment.
When you acknowledge Close in the Debug Status window, you have finished downloading the code into the simulator and you are ready to run your code.
A Pleasant Note:- Many of these steps occur automatically the second time that you open the Debug window . You'll need to activate some of the "features" available with the SDS tool-kit. This automation greatly speeds loading your code and getting to the simulation stage.
Note:- Those of you who have used the built-in SDS assembler interface will not experience all of the problems discussed below. This is due to the fact that this interface does not allow us to investigate the effect of turning some of the assembler options off; an ability that operating from the DOS window does permit.
You should be able to see a Source window. There will be a green arrow marked PC pointing to memory location hexadecimal 00000000. We want to get the PC to point to the start of our code and have the Source window display this code while the simulation occurs.
Just above the green PC
arrow is a bar with the (hex) number 00000000. Click on that
number. In the Show Label/Address window that
appears enter mycode, the label for the start of our
program segment. The SDS toolkit understands exported labels
under most situations. In this case, using the mycode
label will cause the display of the memory locations containing
our executable file.
In the Source
window control bar there is an option button currently marked Source.
Activate this button and select Mixed. This will allow a
mixture of source and machine instructions to be displayed when
the SDS options are set up correctly. Currently the Source
window shows the machine instructions and their hexadecimal
(machine code) equivalents. Activating the mixture of source and
machine instructions means that comments, and other information,
are available inside the simulator, making debugging far easier.
Either use the main window Window option, or click on the RegWin button in the Toolbar to bring up a Register window. Adjust the window size until you can see the PC value, currently showing 0x0. Double click on the PC value to bring up a Enter Register Value window. Type in the starting position of our code 0x1000. Unfortunately, this part of the simulator does not know about the label mycode. Perhaps later versions will.
If you have a small SDS window, the Register and Toolbar windows may be hidden off to the right side of the screen. You'll have to fool around with the window positions in order to see everything that you want.
The fact that we have set
the PC to the start of our code segment is shown in the Source
window by the green PC arrow.
WARNING:- check that the value you thought you entered in for the PC value actually got entered. I often end up with an extra 0x in the value (and sometimes no 0x) or an extra space especially when using the delete key to modify a register value.
Either select the GO option from the main Run menu or else the GO button from the Toolbar.
At this point, your program will either "run forever" or else "crash" with an illegal instruction or BUS error message. If your code is still running after the GO then select STOP from the main Run menu or from the Toolbar. If you get an Error window then clicking on OK should clear the window and stop the simulation.
The code was executed correctly, but we never told the simulation to stop when we got to the end of the HVZ code. Something else we need to fix.
On occasion I have managed to get an Error window that has the message simulator only supports 68K of memory. Clicking on the OK button five or six times usually clears this. On occasion it does not, and I can't clear without rebooting the computer. Then I use the approach suggested when you follow this link.
If you go to the memory specification button in the Source window and enter in 0x7200, we can see the value stored in this memory location by our code. Alternately, bring up a Window window and enter in the address 0x7200 there.
This was the memory location pointed to by variable "C". Check the value, the code did work! You can also see that the code worked by looking in the Register window. The PC value is no longer at the start of our code (0x1000).
We can't use the "C" label name to locate the memory location 0x7200 as we used the "mycode" label to locate location 0x1000. This is because we did not EXPORT the "C" label as we did the "mycode" label (something else to fix). The assembler language directive EXPORT means that the assembler/linker generate the appropriate code so that the simulator will recognize the meaning of the labels we used in the source code file. This is a very useful debugging tool. (As will be seen later, we need to do more than just export the label "C".)
At memory location 0x7200 we see the line
00007200: 01A8 0000 BCLR.B D0, (0.W, A0)
The 16-bit value 0x01A8 is the expected sum (in hex) of 639 and -215. Ignore the instruction BCLR.B D0, (0.W, A0). The SDS toolkit is simply trying to interprete what was stored in memory in as many useful ways as possible. In this case, the number means something and the instruction does not. You'll find a similar effect if you look at memory location 0x2000 where the 16-bit constants A and B are stored.
We need to be able to run the code in a more controlled manner than with this random "crash-to-exit" approach. It would be all to easy, for the processor to find an infinite loop somewhere in memory and never stop.
![]() |
Last modified: July 14, 1996 06:40 PM by M. Smith. Copyright -- M. R. Smith