Getting a Simulator for the 68000
and Running Code on It
(Hatari, vasm)
Again, I'm assuming you've gone through the previous chapters, bringing EXORsim up for the 6800 and 6809 and running code on it, and also bringing up my fork of EXORsim for the 6801, with code running on it as well.
I'll be implicitly referring here and there back to things we did in those chapters, so if you get lost, at least go back and make sure you've read and understood those and preferably got those emulators working before leaving questions here.
Now, if someone had written an EXORmacs simulator in the same vein as Joe
Allen's EXORsim, we'd be in business. I'd use that for the 68000 code here. Or
even an EXORsim simulator for the MEX68KDM 68K developer module card for the
EXORciser that Motorola mentioned in some of their materials.
(I seem to remember a simulator for a Versabus or VME based computer in the
SIMH project, but I'm not seeing that now. I probably should take a look at
the SAGE simulator in openSIMH, but, again, that's a lot of reading
documentation and building more code, and I'm not sure it would be any easier to
use than Hatari.)
There's also Easy68k or something, but it only runs on MSWindows, and I don't do Wine, and I don't recommend things I don't do.
So, options lacking, doing this (myself) right for the 68000 would possibly involve something like writing up an instance of Musashi that would run in some sort of terminal arrangement, perhaps as an alternate history main processor board for the EXORciser if I can't find documentation for the MEX68KDM.
Or do something to emulate the single board MEX68KECB.
And I'm not sure how much of the disassembler, general debugger, interactive assembler, etc. I'd have to add, so maybe I might as well plan on writing the emulator proper, as well, instead of planning on using Musashi.
And all of that would be more postponing this tutorial.
So, ...
Hatari
What's the difference between an emulator and a simulator?
Some people say that emulators are done in hardware and simulators in
software. But the
Hatari project
calls their Atari ST simulator an emulator.
Hatari is in the Debian package repositories, and therefore in Ubuntu and many other Linux OS package repositories, as well. And there are RPMs for Cent OS and such. You can download it from the project site and work through getting all the prerequisite dependencies installed before building it yourself if you want. But that's another steep learning curve if you haven't done it before, and a fair amount of work even if you have.
Although that's exactly what I have done in my current workstation. I
installed the dependencies syetem-globally from packages, then built Hatari and installed it
locally in my daily-driving user account. It keeps the side-effects local.
So having it in packages is a really useful thing if you aren't building it yourself. Your package manager can work out the dependencies, and install them all together at once with Hatari, in just a few minutes or tens of minutes, depending on your internet connection.
Fortunately for you who are running MSWindows, there are pre-compiled .exe
executables for you in the
downloads area
of the website, in .zip archives.
Go ahead and spend a few minutes looking around the Hatari site, especially the docs. Things to look for,
- EmuTOS
- Keyboard mappings
- Disk images
- Emulating disks in hosted directories
- Getting Hisoft Devpac or similar software
-
The built-in debugger
Check to see if your package manager includes Hatari. (Cygwin for MSWindows
does not, at present. Several package managers for Mac do. Most Linux OSses
do. NetBSD and FreeBSD do.)
If it doesn't, spend some time checking the build instructions. Write down the list of dependencies and start collecting and either installing them from packages or building them. Etc. LoL. If you are running an OS for which you need to build it, I'm pretty sure you know how to do this without me explaining it.
If, for whatever reason, you do build it yourself, you can specify your local executable directory as the install target. In the example structure I've been talking about, that might be
~/prg
and in that case you would specify
/home/me/prg
as the target.
Before we proceed, there is a not-so-minor issue with Hatari, in that we won't be able to do things like copying and pasting object or assembler source code into the running emulator window, the way we can with EXORsim. We'll have to edit source code files, save them in the directories Hatari is seeing as emulated disk, and assemble them with vasm or something similar.
Speaking of directories, familiarize yourself with the directory structure your package system sets up for Hatari. In particular, as I mentioned, you want to know where to put EmuTOS so it can find it, or, more likely, you want to check where your package has installed EmuTOS. You also want to know where it will look for disk images and directories to emulate disks in.
If you have it installed properly, you can find a lot of answers by running
$ hatari --help
Hatari v2.4.0-devel (Dec 18 2021) - the Atari ST, STE, TT and Falcon emulator.
Hatari is free software licensed under the GNU General Public License.
Usage:
hatari [options] [directory|disk image|Atari program]
General options:
--help or -h Print this help text and exit
...
EmuTOS
EmuTOS is
essentially a free-and-open-source replacement for TOS (in the short version
of the story) -- the BIOS and OS kernel provided originally by Atari.
You may find people telling you you need to download EmuTOS separately from Hatari, but that really isn't the case for our uses. The license for EmuTOS allows it to be packaged with Hatari and other emulators, so the tos.img that is in the package that your package manager makes for you, or is in the .zip or other archive you downloaded, should be EmuTOS.
That also means you don't have to extract the ROM from a real Atari ST or such to do what we want to do.
Setup
In fact, other than deciding where to set up the shared directory structure, it should just mostly work. Well, that and the keyboard mappings. You'll probably want to look carefully at keyboard mappings so you can get an idea where to find keys you need.
Once it's installed (or built), running hatari from the command line without options should bring up an Atari desktop screen in emulation, like this:
from which you can hit F12 to get a graphical dialog to set things up.
You may prefer to go that route, rather than sort through all the command-line
options. Heh. You probably do want to use it. So I'll walk you through the relevant setup.
By the way, F11 toggles full-screen mode off and on. This is useful, particularly when switching back and forth between Hatari and your host OS.
You will usually want to use it with full screen off, because of all the
things you'll be doing at the same time on the host machine. But, at least on
my installation, with full-screen off, the mouse sometimes gets out of sync,
and I have to toggle back to full-screen to use the mouse. However, I can
pretty much always use the mouse in the setup dialog. Toggling is not usually
a problem.
Things you want to set up or check now include
-
System -- Keep it ST mode to keep things simple.
Blitter in ST mode, if it isn't already set. -
CPU -- 8 MHz can be slow, but more than 16 MHz can get weird.
So, 16 MHz.
-
Memory -- You want at least 512K, and more than that can get weird for what
we are doing.
So, 512K.
-
Floppy disks and Hard disks -- You don't really need disk images, but, maybe
you do ...
We've got to talk about default directories for a moment.
When you install from your packages, it will likely set up several things it needs to keep track of under
/usr/local/share/hatari/
or some such directory. This is in the file system area controlled by the operating system, and is outside your daily driving user's file system area. Handling file permissions to allow writing here can get strange. You should not want to do that. No, you really should not want to do that. So you'll want to make some adjustments.
Among the things it will by default save here, and look for here, are
- the tos.img file it is using
- the C: directory
- keyboard mapping files
- disk image files
I'm sure you can understand that we need these, and we need to know where they are.
The tos.img file, we can leave alone, once we've noticed where it is. We won't
need to touch it that much. (If we do need to, if we have a different tos.img
file to use, the configuration menu lets select a different image in a different location without
messing with /usr/local/share/.)
The C: directory mapping, we will use extensively. We need to write to that directory a lot. So we need to point it somewhere within our daily-driver working directories, like (using unix/Linux syntax)
~/asmwork/share/hatari/C/
which if you are working as user "me" on a LInux OS, might actually look like
/home/me/asmwork/share/hatari/C/
I say might because it depends on how you set things up. I didn't set mine up exactly this way, but I'll use this as a basis to explain things. You should think a little about how you would want it, and set it up in a way that makes sense to you.
Your operating system gives you some sort of a home directory for the user you are logged in as, and the directory you decide to do most of your assembly language work in should reside under that. That directory would be "asmwork" in the paradigm above, or it could be "mywork/asm", or whatever you choose to call it. You'll probably want a directory under that which multiple programs you'll be working with can share, there under your assembly language working directory, and you might call it "share" -- thus, "asmwork/share" if you decide to do it that way.
On MSWindows, you'll be wanting to work within the cygwin shell, so you'll use
forward slashes instead of MS-DOS/CPM backslashes (or instead of yen mark -- ¥
-- in older Japanese language MSWindows OSses). But looking at them or
working on them in MSWindows command line shell, you will use the MSWindows
slash -- "<something>\asmwork\share\hatari\C\" (or, in an older Japanese
MSWindows OS, the yen mark --
"<something>¥asmwork¥share¥hatari¥C¥"). You'll need to get used to some
differences between the Cygwin shell and the MSWindows shell.
Not incidentally, I downloaded the 80 megabyte hard disk blank image that you can find on the Hatari download page and saved it in my local files, and saved a copy of it to be used as the hatari D: drive, for example, directly under
~/asmwork/share/hatari/
in the above directory conventions. I recommend you get that hard disk image
and save it somewhere similar, also. You can then select it for your D: drive
from the configuration dialog.
So, continuing with the configuration dialog:
-
Hard disks -- write down the default for C: before you use eject and browse
to set it appropriately in your own directory structure. You might want to
remember where it was.
Also, set up a D: drive with the blank image, as an IDE drive.
When you're done with this, save the configuration once, just to be sure. -
Floppy disks -- you can probably save yourself some error messages if you
use the configuration dialog to create a couple of blank floppy images and
set them up to be drives A: and B:. The setup dialog has buttons that do
this for you.
-
Atari Screen -- look at what's here, in case you want to change something.
But leave it at resolutions and colors the early ST models can handle, so
things don't get weird.
-
Hatari Screen -- You probably want the status bar and GPU scaling.
-
Keyboard -- Remember that you can set the keyboard mapping here. In fact, go
ahead and save a default configuration file in your local directories so you
can look at it and play with it.
- Load/Save config -- Note where it saves your configuration files in a hidden directory in your local directory structure, which is not under ~/asmwork/share/hatari/ in the above conventions. Quite likely, it will be under "~/.config/hatari/",
So far, even if it isn't anything that seems all that interesting, you just need to see where things are, and, especially, move C: and save and set some keyboard mappings.
Go ahead and quit after saving anything you changed and want to save. It will give you one last chance to save things.
Check again in your host OS that the C: directory is where you told it to be,
for example, under the above conventions,
~/asmwork/share/hatari/C/
Start Hatari again and when the desktop screen comes up, run EmuCON by selecting it from the File menu.
Or you can just hit Ctrl-Z to run EmuCON. Either way works.
It should put away the GUI screen and drop you into a command-line DOS (ergo, CP/M) shell.
Type some commands like HELP and DIR and such (You don't have to type in caps.), and see whether the keyboard needs configuration. If it does, look at the documentation and figure out what needs to be where.
The following keyboard configuration file makes hyphen, brackets, and the
caret available on my Japanese notebook keyboard, although not in optimal
positions.
-,12
[,26
],27
^,13
Some other key codes, I have to use the Fn key and the keypad to access.
You'll have to figure out what your keyboard needs, though, and it requires editing the keyboard configuration file as a text file in your host system, so don't hesitate to use pencil and paper if necessary to take notes. And be willing to make compromises, because they are trying to emulate the ST keyboard, not make the modern keyboard available in its entirety.
When you have the keyboard working well enough, use EmuCON to make a working
directory under the C: directory. You could do this in the host OS, as well,
but we want to make sure the emulator is working and able to talk to the host
OS on things like this. In the EmuCON console,do a DIR and see what the
emulator thinks is there.
C:\>DIR
file not found
make your working directory, maybe call it "PRIMER", and then change to it for fun:
C:\>MD PRIMER
C:\>DIR
PRIMER
C:\>CD PRIMER
C:\primer>
You can exit the command line shell with the EXIT command.
Devpac
I have been using Hisoft's Devpac for another project, and I was intending to discuss that, but when I went back to check where I got it from and such, I decided there is too much ambiguity and lack of provenance to recommend it. I found some evidence at the time that the folks at Hisoft had given explicit permission, but I can't find that evidence now.
If you want to use it, you'll need to figure out the provenance and whether there is permission to use it for yourself. I can't help you with that.
If you do decide to use Devpac, install it on the D: drive. It'll be easier to use that way.
More generally, you'll probably want to install any tools for working in the
emulated Atari ST system in the emulated D: drive.
Now, as I think I mentioned, Hatari has a built-in debugger. So we have the
debugger requirement at least partially covered.
But it doesn't do interactive assembly, and it doesn't include a separate
assembler, so you'll need an assembler. I haven't written one of those for the
68000. But a guy named Volker Barthelmann and a guy name Frank Wille have
worked together and made something that can help us, called vasm, and
made it available for non-commercial use -- which I think covers what we are
doing here.
vasm
I guess vasm is named for "Volker's Assembler". It's a really complicated beast, and does way more than we need, but we can use it for what we need. As I just said, they have made it available to be used for non-commercial purposes when used to target Atari ST. That's not a license that allows it to be included in your libre OSes's main/libre packages, but it should be sufficent for our purposes here. And it's not hard to build. And not really hard to run. either, once you've got it built.
That is, I'll help you figure out how.
First, nose areound the website. Read the small tutorial. Open up the HTML manual and read the General entry first where it talks about permission to use and about installation. Then go to the entries on the Assembler, the (Motorola) Mot Syntax Module, the TOS output module, and the m68k CPU module, in particular, and read those. Then read the build instructions.
Then download the
latest release source
to someplace like "~asmwork/vasm/" and unpack and build it.
In brief,
- Go to the directory that unpacking the tarball created and do a directory listing. Note all the makefiles.
-
Run make without arguments:
$ make
Ignore the feedback. - Now run
$ make CPU=m68k SYNTAX=mot -
Do a listing
$ ls -lart
and check that vasmm68k_mot has been built. - Link it into your local user file system's binary directory.
Given the example directory structure I've been mentioning, that last step can be done with something like
ln -s /home/me/asmwork/vasm/vasm/vasm68k_mot /home/me/prg/
Now we want our sample program that accumulates a few sums. This time we'll have to actually put it in a file instead of editing it interactively in the simulator.
Here's the code again, with stuff that's necessary for vasm and for the
Atari ST target, and a little extra code inspired by the extra we did with the
6801:
OPT LIST,SYMTAB ; Options we want for the stand-alone assembler. MACHINE MC68000 ; because there are a lot the assembler can do. OPT DEBUG ; We want the debugger to know our labels. OUTPUT *********************************************************************** EVEN ; Just for good measure -- 68K needs code even aligned. EXAMPLE: MOVEQ #8,D0 ; MOVEQ lets us ignore register width. ADDQ #5,D0 ; Default register width is okay. ADDQ #2,D0 ; D0 is comparable to 6800 A? Sort-of? Maybe? ADDQ #7,D0 ADDQ #4,D0 NOP ; one landing pad RESTART: MOVE.W #2056,D0 ; the extra example for 6801 ADD.W #1285,D0 ADD.W #514,D0 ADD.W #1799,D0 ADD.W #1028,D0 NOP ; two landing pad DRESTART: MOVE.L #134744072,D0 ; 32-bit version ADD.L #84215045,D0 ADD.L #33686018,D0 ADD.L #117901063,D0 ADD.L #67372036,D0 NOP ; three landing pad DONE: NOP ; You must "quit" the debugger. NOP ; Don't continue. END EXAMPLE
In your host OS, copy that into an empty text editor document and save it in your working directory for the primer code as something like sum85274.s. Given the above structure, that would be
~/asmwork/share/hatari/C/primer/sum85274.s
Drag the corner of your terminal shell window to widen it to mostly fill the
screen before you continue. It'll make it easier to shift back to the terminal
when you start debugging.
Assemble the file you just saved with vasm using the vasmm68k_mot command with
parameters as follows:
$ vasmm68k_mot -Ftos -o SUM85274.PRG -L sum85274.lst sum85274.s
You can open the assembly listing file, sum85274.lst, in a text editor, to
look at the results.
If there are no errors, start Hatari there in the primer working directory:
$ hatari
When the desktop comes up, hit Ctrl-Z to bring up EmuCON. In EmuCON, change to the primer working directory, whatever you named it.
Then hit Alt-PAUSE to enter the debugger.
That's the alt key, with the PAUSE function key that is usually above the ten-key pad on a long keyboard, or at the top-right corner of the notebook PC keyboard. If you are working on a notebook computer, you probably need to hold down the Fn key while you hit Alt-PAUSE.
Sometimes, my computer seems to miss the Alt key and just pauses. If that happens, you may have to hit Alt-PAUSE again to enter the debugger.
When you enter the debugger, the emulated Atari screen may see some pixel folding. That's okay, ignore it.
Move the host OS cursor over to the terminal shell window where you started
Hatari, and click that window to bring it forward:
At this point, you're debugging the Atari ST operating system itself, or
perhaps EmuCON.
----------------------------------------------------------------------
You have entered debug mode. Type c to continue emulation, h for help.
CPU=$e1d7e2, VBL=790, FrameCycles=128, HBL=0, LineCycles=128, DSP=N/A
00e1d7e2 46c0 move.w d0,sr
>
Let's try the help command, just to see what help it gives us:
> h Generic commands: cd ( ) : change directory evaluate ( e) : evaluate an expression help ( h) : print help history (hi) : show last CPU/DSP PC values & executed instructions info ( i) : show machine/OS information lock ( ) : specify information to show on entering the debugger logfile ( f) : set (memdump/disasm/etc) log file parse ( p) : get debugger commands from file rename ( ) : rename given file reset ( ) : reset emulation screenshot ( ) : save screenshot to given file setopt ( o) : set Hatari command line and debugger options stateload ( ) : restore emulation state statesave ( ) : save emulation state trace ( t) : select Hatari tracing settings variables ( v) : List builtin symbols / variables quit ( q) : quit emulator CPU commands: address ( a) : set CPU PC address breakpoints breakpoint ( b) : set/remove/list conditional CPU breakpoints disasm ( d) : disassemble from PC, or given address profile ( ) : profile CPU code cpureg ( r) : dump register values or set register to value memdump ( m) : dump memory memwrite ( w) : write bytes/words/longs to memory loadbin ( l) : load a file into memory savebin ( ) : save memory to a file symbols ( ) : load CPU symbols & their addresses step ( s) : single-step CPU next ( n) : step CPU through subroutine calls / to given instruction type cont ( c) : continue emulation / CPU single-stepping DSP commands: dspaddress (da) : set DSP PC address breakpoints dspbreak (db) : set/remove/list conditional DSP breakpoints dspdisasm (dd) : disassemble DSP code dspmemdump (dm) : dump DSP memory dspsymbols ( ) : load DSP symbols & their addresses dspprofile (dp) : profile DSP code dspreg (dr) : read/write DSP registers dspstep (ds) : single-step DSP dspnext (dn) : step DSP through subroutine calls / to given instruction type dspcont (dc) : continue emulation / DSP single-stepping If value is prefixed with '$', it's a hexadecimal, if with '#', it's a normal decimal, if with '%', it's a binary decimal. Prefix can be skipped for numbers in the default number base (currently 10). Any expression given in quotes (within ""), will be evaluated before given to the debugger command. Any register and symbol names in the expression are replaced by their values. Note that address ranges like '$fc0000-$fc0100' should have no spaces between the range numbers. 'help <command>' gives more help. >
You can try various commands, like disassembling code (d), dumping memory (m), and looking at registers (r). But don't try setting memory or registers just yet.
If you do, you'll want to use the quit (q) command and start Hatari up again
fresh.
The problem you might be wondering about is how to get the target program into
memory where you can debug it. I think it might be possible to use the
debugger's load command (l), but, if so, I haven't figured that out yet.
Instead, as described in the debugger manual entry on breakpoints and variables, set a breakpoint to stop emulation after a program is loaded and before it is run with this break command:
b pc = TEXT :once
Here's what it looks like typed in, with the results it displays:
> b pc = TEXT :once
CPU condition breakpoint 1 with 1 condition(s) added:
pc = TEXT
-> Break only once, and delete breakpoint afterwards.
>
What that means is that it set a one-time breakpoint for the next time the PC is equal to the beginning of the TEXT segment. CP/M programs are started by starting execution at the beginning of the program's TEXT segment, so this will do what we want, if we make sure that the next program we run is the target program.
Use the continue command (c) to let Hatari continue running,
> c
Returning to emulation...
and then bring the Hatari window back in front using the task bar or whatever. EmuCON should be showing you an active prompt there.
At the prompt, type the name of the executable file that you just used vasmm68k_mot to create. If you used the same names as I did, above, that would be
C:\primer>SUM85274.PRG
with or without the .PRG extension, really.
Now use the task bar or whatever to get back to the console where the debugger
will be showing you all sorts of things about the breakpoint, showing you the
first instruction in the TEXT segment disassembled, and prompting you again:
1. CPU breakpoint condition(s) matched 1 times.
pc = TEXT :once
Removed CPU breakpoint 1:
pc = TEXT :once
Reading symbols from program '/home/nova/usr/share/hatari/C:/primer/SUM85274.PRG' symbol table...
TOS executable, DRI / GST symbol table, reloc=0, program flags: PRIVATE (0x0)
Program section sizes:
text: 0xc, data: 0x0, bss: 0x0, symtab: 0xe
Trying to load DRI symbol table at offset 0x28...
Offsetting BSS/DATA symbols from TEXT section.
Skipping duplicate address & symbol name checks when autoload is enabled.
Loaded 1 symbols (1 TEXT) from '/home/nova/usr/share/hatari/C:/primer/SUM85274.PRG'.
CPU=$13d10, VBL=20873, FrameCycles=241160, HBL=237, LineCycles=368, DSP=N/A
00013d10 7008 moveq #$08,d0
>
Notice that disassembly of the first instruction at the end of all that. We're ready to do a MOVEQ, ready to load D0 with the value 8.
We can do a disassembly, and the debugger will just assume, since we haven't done a disassembly during this session yet, that we want to see what the current PC is pointing out:
> d
(PC)
EXAMPLE:
00013d10 7008 moveq #$08,d0
00013d12 5a40 addq.w #$05,d0
00013d14 5440 addq.w #$02,d0
00013d16 5e40 addq.w #$07,d0
00013d18 5840 addq.w #$04,d0
00013d1a 4e71 nop
RESTART:
00013d1c 303c 0808 move.w #$0808,d0
00013d20 d07c 0505 add.w #$0505,d0
00013d24 d07c 0202 add.w #$0202,d0
00013d28 d07c 0707 add.w #$0707,d0
00013d2c d07c 0404 add.w #$0404,d0
00013d30 4e71 nop
DRESTART:
00013d32 203c 0808 0808 move.l #$08080808,d0
00013d38 d0bc 0505 0505 add.l #$05050505,d0
00013d3e d0bc 0202 0202 add.l #$02020202,d0
00013d44 d0bc 0707 0707 add.l #$07070707,d0
00013d4a d0bc 0404 0404 add.l #$04040404,d0
00013d50 4e71 nop
00013d52 4e71 nop
>
Let's do a second disassembly to see if it has shown us all of the code. This time, it will pick up at where it left off:
> d
00013d54 0000 0000 or.b #$00,d0
00013d58 0000 0000 or.b #$00,d0
00013d5c 0000 0000 or.b #$00,d0
00013d60 0000 0000 or.b #$00,d0
00013d64 0000 0000 or.b #$00,d0
00013d68 0000 0000 or.b #$00,d0
00013d6c 0000 0000 or.b #$00,d0
00013d70 0000 0000 or.b #$00,d0
00013d74 0000 0000 or.b #$00,d0
00013d78 0000 0000 or.b #$00,d0
00013d7c 0000 0000 or.b #$00,d0
00013d80 0000 0000 or.b #$00,d0
00013d84 0000 0000 or.b #$00,d0
00013d88 0000 0000 or.b #$00,d0
00013d8c 0000 0000 or.b #$00,d0
00013d90 0000 0000 or.b #$00,d0
00013d94 0000 0000 or.b #$00,d0
00013d98 0000 0000 or.b #$00,d0
00013d9c 0000 0000 or.b #$00,d0
00013da0 0000 0000 or.b #$00,d0
00013da4 0000 0000 or.b #$00,d0
00013da8 0000 0000 or.b #$00,d0
00013dac 0000 0000 or.b #$00,d0
>
Yep, when there's nothing in memory, there's usually a lot of zeroes or a lot
of garbage. And zeroes just happen to be the op-code for a byte-sized OR of
immediate 0 into D0.
Try single stepping (s):
> s
CPU=$13d12, VBL=32348, FrameCycles=35072, HBL=34, LineCycles=528, DSP=N/A
00013d12 5a40 addq.w #$05,d0
>
Unfortunately, it doesn't show you which register(s) changed. It does show you the CPU and the next op-code, disassembled, along with a lot of display controller stuff. We want to see the registers, so, let's use the register command (r):
> r
D0 00000008 D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 00000000
A0 00000000 A1 00000000 A2 00000000 A3 00000000
A4 00013D54 A5 00013D54 A6 00077FC6 A7 00077FF8
USP 00077FF8 ISP 00007E64
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
Prefetch 5a40 (ADD) 5440 (ADD) Chip latch 00000000
00013d12 5a40 addq.w #$05,d0
Next PC: 00013d14
>
So, if you step (s) and then show (r) the registers, you can watch the numbers
add up (in hexadecimal) in data register D0.
> s
CPU=$13d14, VBL=32348, FrameCycles=35076, HBL=34, LineCycles=532, DSP=N/A
00013d14 5440 addq.w #$02,d0
> r
D0 0000000D D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 00000000
A0 00000000 A1 00000000 A2 00000000 A3 00000000
A4 00013D54 A5 00013D54 A6 00077FC6 A7 00077FF8
USP 00077FF8 ISP 00007E64
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
Prefetch 5440 (ADD) 5e40 (ADD) Chip latch 00000000
00013d14 5440 addq.w #$02,d0
Next PC: 00013d16
> s
CPU=$13d16, VBL=32348, FrameCycles=35080, HBL=34, LineCycles=536, DSP=N/A
00013d16 5e40 addq.w #$07,d0
> r
D0 0000000F D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 00000000
A0 00000000 A1 00000000 A2 00000000 A3 00000000
A4 00013D54 A5 00013D54 A6 00077FC6 A7 00077FF8
USP 00077FF8 ISP 00007E64
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
Prefetch 5e40 (ADD) 5840 (ADD) Chip latch 00000000
00013d16 5e40 addq.w #$07,d0
Next PC: 00013d18
> s
CPU=$13d18, VBL=32348, FrameCycles=35084, HBL=34, LineCycles=540, DSP=N/A
00013d18 5840 addq.w #$04,d0
> r
D0 00000016 D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 00000000
A0 00000000 A1 00000000 A2 00000000 A3 00000000
A4 00013D54 A5 00013D54 A6 00077FC6 A7 00077FF8
USP 00077FF8 ISP 00007E64
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
Prefetch 5840 (ADD) 4e71 (NOP) Chip latch 00000000
00013d18 5840 addq.w #$04,d0
Next PC: 00013d1a
> s
CPU=$13d1a, VBL=32348, FrameCycles=35088, HBL=34, LineCycles=544, DSP=N/A
00013d1a 4e71 nop
> r
D0 0000001A D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 00000000
A0 00000000 A1 00000000 A2 00000000 A3 00000000
A4 00013D54 A5 00013D54 A6 00077FC6 A7 00077FF8
USP 00077FF8 ISP 00007E64
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
Prefetch 4e71 (NOP) 303c (MOVE) Chip latch 00000000
00013d1a 4e71 nop
Next PC: 00013d1c
>
Exciting, isn't it?
Just don't step past the end of code!!!!!!!
Heh. Actually, it's not a problem, as long as you don't step too far. All those
OR #0,D0
instructions don't really do much. They just really aren't very interesting.
But once you've stepped through the end of the code, then what?
If you try to continue executing code that isn't there, something bad will eventually happen, right?
Sort, of. You'll get a segment error or a bus error or some such, and EmuTOS will try to catch you and send you back to the EmuCON window or something. But we can't guarantee that Hatari is in a stable state. (It's almost guaranteed for this one, but not quite.) So, instead, once you've stepped through all the code and convinced yourself it's doing what it's doing, just use the quit command (q) again and quit the Hatari session.
We'll look at how to get the program to safely return to the OS later, among other things
And that should get us started for working on the 68000.
Amiga emulators would also be interesting, but the Amiga run-time has some complexities that I don't want to deal with. Likewise the classic Macintosh systems.
I'm not saying don't try them. Do, if you are inclined. They're fun, but distracting. MAME, too. MAME is really distracting.
I really wish I had time to write an open-source emulator for the
MEX68KECB single board. That would be the least distracting for this
level of code.
Just for the record, MDOS for the EXORciser is approximately what TOS (and EmuTOS) for the Atari is. If the debugger for Hatari were able to assemble code interactively, we would not need, at this level, to be saving code in files and so forth on the Hatari.
But we will get there before we are done. Don't worry.
I think we can get Hatari to do the job we need.
Next, I think I want to show you one way to separate the numbers we're adding in this example from the code itself.
