+
-Version 1.4 +Version 1.7, June 2013
Manual written by: Thomas Huth, Matthias Arndt & Eero Tamminen
-Hatari on the WWW: http://hatari.berlios.de/ +Hatari on the WWW: + +http://hatari.tuxfamily.org/ +
--Hatari is an Atari ST, STE, TT and Falcon emulator for Linux, FreeBSD, BeOS and -other Systems which are supported by the SDL library. +Hatari is an Atari ST, STE, TT and Falcon emulator for Linux, OSX, +Windows and other Systems which are supported by the SDL library. The emulator is open source software and is distributed under the terms of the GNU General Public License (GPL). @@ -166,18 +104,20 @@ Unlike many other Atari ST emulators whi environment for running GEM applications, Hatari tries to emulate the hardware of a ST as close as possible so that it is able to run most of the old ST games and demos. Of course you can run normal GEM applications with Hatari, too. -Recent versions of Hatari even feature basic STE, TT and Falcon emulation. +Recent versions of Hatari even feature STE, Falcon and basic TT emulation.
-There is support for following additional STE features:
There is support for following additional TT features:
There is support for following additional Falcon features:
Hatari currently has the following system requirements:
+Hatari currently has the following minimum system requirements:
-Certain versions of Hatari have successfully been tested by various people on +In the course of time Hatari has successfully been tested by various people on the following systems:
First, you need the SDL library, you can get it at: -http://www.libsdl.org/. Most -distributions already ship a suitable version. -Make sure to install the appropriate header files as well often called -"libsdl-dev" or the like. -
-Second, you need the zLib compression library. You can get it from http://www.gzip.org/zlib/ -but the version shipped with your distribution will be sufficient in -most cases. Make sure to have the header files -for it installed as well. -
+Required:
+Optional:
+-For optional features like PNG format screenshots and Hatari window -embedding, you need to have the header files for libpng and libX11. -For Falcon microphone recording support portaudio library is needed. +The versions available in your Linux distribution will be sufficient +in most cases, but make sure you have also the header files installed +for the libraries as well! Typically they're in a corresponding -dev +package.
+-Of course, you need the GNU C compiler and (GNU) Make, too! -
-Change to the hatari/ directory, copy -Makefile-default.cnf to -Makefile.cnf and adapt the configuration file -to suite your system. Alternatively, you can use the supplied configure -script to auto-detect all parameters (type -"./configure --help" -to see the options of the script). -Don't forget to use some good CFLAGS for the compiler optimizations, e.g. -run configure in the following way: -
+After you've verified that you have the required libraries and their +development files, change to the hatari/ +directory. Create a build/ directory under +it and configure the build system for your environment:-CFLAGS="-O3 -fomit-frame-pointer" ./configure +mkdir -p build +cd build +cmake ..
Then compile Hatari by typing make. -If all -works fine, you'll get the executable hatari +If all works fine, you'll get the executable hatari in the src/ subdirectory.
++Note: Instead of calling CMake directly, you can also use the supplied +configure script to run CMake and to give the arguments (like install +prefix) in a format familiar from GNU Autotools using programs. Type +"./configure --help" +to see all the options supported by this script. +
-Before you can start Hatari, you have to copy a TOS ROM image to the data -directory (the data directory is specified -in the configuration file Makefile.cnf) and +directory (<prefix>/share/hatari/, by +default /usr/local/share/hatari/) and rename it to tos.img, or use the --tos command line option to tell Hatari where to find a TOS ROM. @@ -361,19 +312,18 @@ more details), but it's free and compati find a suitable TOS image in the default dir, you'll get the chance to select a TOS image file from the GUI.
-Type make install as root to do a -systemwide installation. In this case it is recommended -to set the DATADIR variable in Makefile.cnf to a proper value. /usr/local/share/hatari -is a good value in that case.
-The Hatari executable should now be in your PATH and accessible from -anywhere.
+Type make install as "root" user to +do a systemwide installation.
+Assuming you didn't change the default installation prefix and that +/usr/local/bin/ is in your PATH, you should +be now able to start the Hatari executable from anywhere.
When you finally have got a TOS image, try starting Hatari with the option --help to find out more about its command line parameters.
-Now type hatari to run the emulator for the first time. If all goes @@ -384,1140 +334,487 @@ to turn on the GUI to configure Hatari to suit your needs, press F11 to toggle windowed and fullscreen mode.
-Hatari settings can come from several sources, with later ones +overriding the earlier given ones: +
Some of the run-time changes require emulation to be reseted for them +to take effect.
+ + +Usage:
- hatari [options] [disk image name] + hatari [options] [disk image | directory | Atari program ]+
As an argument one can give either a name of:
+Booting will be done from the disk image or directory that's given +last on the command line as an option or the argument (and which +corresponds to A: or C:).
+Hatari command line options are split into several categories:
-| - | --h, --help | -
| - | -Print command line options and terminate - | -
| - | --v, --version | -
| - | -Print version information and terminate - | -
| - | ---confirm-quit <bool> | -
| - | -Whether Hatari confirms quitting - | -
| - | --c, --configfile -<filename> | -
| - | -use the given file as configuration file instead of -~/.hatari/hatari.cfg - | -
| - | ---fast-forward <bool> | -
| - | -On fast machine helps skipping (fast forwarding) Hatari -output - | -
| - | --m, --mono | -
| - | -Start in monochrome mode instead of color - | -
| - | ---monitor <x> | -
| - | -Select monitor type (x = mono/rgb/vga/tv) - | -
| - | --f, --fullscreen | -
| - | -Start the emulator in fullscreen mode - | -
| - | --w, --window | -
| - | -Start the emulator in window mode - | -
| - | ---grab | -
| - | -Grab mouse (also) in window mode - | -
| - | --z, --zoom <x> | -
| - | -Zoom low resolution (1=no, 2=yes) - | -
| - | ---max-width <x> | -
| - | -Maximum window width for zooming (Falcon/TT only) - | -
| - | ---max-height <x> | -
| - | -Maximum window height for zooming (Falcon/TT only) - | -
| - | ---aspect <bool> | -
| - | -Whether to do monitor aspect ratio correction (Falcon/TT only) - | -
| - | ---borders <bool> | -
| - | -Show ST/STE screen borders (for low/med resolution overscan demos) - | -
| - | ---frameskips <x> | -
| - | -Skip <x> frames after each displayed frame to -accelerate emulation (0=disabled, >4 uses automatic -frameskip with given value as maximum) - | -
| - | ---statusbar <bool> | -
| - | -Show statusbar (with floppy leds etc etc) - | -
| - | ---drive-led <bool> | -
| - | -Show overlay drive led when statusbar isn’t -shown - | -
| - | ---spec512 <x> | -
| - | -Hatari uses this threshold to decide when to render a -screen with the slower but more accurate Spectrum512 screen -conversion functions (0 <= x <= 512, 0=disable) - | -
| - | ---bpp <bool> | -
| - | -Force internal bitdepth (x = 8/15/16/32, 0=disable) - | -
−h, +−−help
+Print command line options and +terminate
+−v, +−−version
+Print version information and +terminate
+−−confirm-quit +<bool>
+Whether Hatari confirms quitting
+−c, −−configfile +<filename>
+Read additional configuration values from +<file>, these override values read from the global and +user configuration files +
+−k, −−keymap +<file>
+load keyboard mapping from +<file>
+−−fast-forward +<bool>
+On fast machine helps skipping (fast +forwarding) Hatari output
+ +−m, +−−mono
+Start in monochrome mode instead of +color
+−−monitor +<x>
+Select monitor type (x = +mono/rgb/vga/tv)
+−f, +−−fullscreen
+Start the emulator in fullscreen +mode
+−w, +−−window
+Start the emulator in window mode
+−−grab
+Grab mouse (also) in window mode
+−−frameskips +<x>
+Skip <x> frames after each +displayed frame to accelerate emulation (0=disabled, >4 uses +automatic frameskip with given value as maximum)
+−−statusbar +<bool>
+Show statusbar (with floppy leds etc +etc)
+−−drive-led +<bool>
+Show overlay drive led when statusbar +isn’t shown
+−−bpp +<bool>
+Force internal bitdepth (x = +8/15/16/32, 0=disable)
+ ++−−borders <bool>
+Show ST/STE screen borders (for low/med +resolution overscan demos)
+−−desktop-st +<bool>
+Whether fullscreen mode uses desktop +resolution to avoid: messing multi-screen setups, several seconds +delay needed by LCD monitors resolution switching and the resulting +sound break. As Hatari ST/E display code doesn’t support +zooming (except low-rez doubling), it doesn’t get scaled (by +Hatari or monitor) when this is enabled. Therefore this is mainly +useful only if you suffer from the described effects, but still +want to grab mouse and remove other distractions from the screen +just by toggling fullscreen mode. (disabled by default)
+−−spec512 +<x>
+Hatari uses this threshold to decide +when to render a screen with the slower but more accurate +Spectrum512 screen conversion functions (0 <= x <= 512, +0=disable)
+−z, −−zoom +<x>
+Zoom (double) low resolution (1=no, +2=yes)
+ +Zooming to sizes
+specified below is internally done using integer scaling factors.
+This means that different Atari resolutions may show up with
+different sizes, but they are never blurry.
+−−desktop <bool>
Whether to use desktop resolution on +fullscreen to avoid issues related to resolution switching. +Otherwise fullscreen will use a resolution that is closest to the +Hatari window size. (enabled by default)
+−−max-width +<x>
+Preferred / maximum window width
+−−max-height +<x>
+Preferred / maximum window height
+−−force-max +<bool>
+Hatari window size is forced to +specified maximum size and black borders used when Atari resolution +doesn’t scale evenly to it. This is most useful when +recording videos of Falcon demos that change their resolution. +(disabled by default)
+−−aspect +<bool>
+Whether to do monitor aspect ratio +correction (enabled by default)
+| - | ---vdi <bool> | -
| - | -Whether to use VDI screen mode - | -
| - | ---vdi-planes <x> | -
| - | -Use extended VDI resolution with bit depth <x> (x = 1, 2 or 4) - | -
| - | ---vdi-width <w> | -
| - | -Use extended VDI resolution with width <w> (320 < w <= 1280) - | -
| - | ---vdi-height <h> | -
| - | -Use extended VDI resolution with height <h> (200 < h <= 960) - | -
| - | ---avirecord | -
| - | -Start AVI recording - | -
| - | ---avi-vcodec <x> | -
| - | -Select avi video codec (x = bmp/png) - | -
| - | ---avi-fps <x> | -
| - | -Force avi frame rate (x = 50/60/71/...) - | -
| - | ---avi-crop <bool> | -
| - | -Remove status bar from the recorded file - | -
| - | ---avi-file <file> | -
| - | -Use <file> to record avi - | -
−−vdi +<bool>
+Whether to use VDI screen mode
+−−vdi−planes +<x>
+Use extended VDI resolution with bit +depth <x> (x = 1, 2 or 4)
+−−vdi−width +<w>
+Use extended VDI resolution with width +<w> (320 < w <= 1280)
+−−vdi−height +<h>
+Use extended VDI resolution with height +<h> (200 < h <= 960)
+ +−−crop +<bool>
+Remove statusbar from the screen +captures
+−−avirecord
+Start AVI recording
+−−avi-vcodec +<x>
+Select avi video codec (x = +bmp/png)
+−−avi-fps +<x>
+Force avi frame rate (x = +50/60/71/...)
+−−avi-file +<file>
+Use <file> to record avi
+| - | --j, --joystick -<port> | -
| - | -Emulate joystick with cursor keys in given port (0-5) - | -
| - | ---joy<port> -<type> | -
| - | -Set joystick type (none/keys/real) for given port - | -
| - | ---printer <file> | -
| - | -Enable printer support and write data to <file> - | -
| - | ---midi-in <filename> | -
| - | -Enable MIDI support and write MIDI data to <file> - | -
| - | ---midi-out <filename> | -
| - | -Enable MIDI support and read MIDI data from <file> - | -
| - | ---rs232-in <filename> | -
| - | -Enable serial port support and use <file> as the input device - | -
| - | ---rs232-out <filename> | -
| - | -Enable serial port support and use <file> as the output device - | -
| - | ---disk-a <file> | -
| - | -Set disk image for floppy drive A - | -
| - | ---disk-b <file> | -
| - | -Set disk image for floppy drive B - | -
| - | ---protect-floppy <x> | -
| - | -Write protect floppy image contents (on/off/auto). With "auto" option -write protection is according to the disk image file attributes. - | -
| - | ---protect-hd <x> | -
| - | -Write protect harddrive <dir> contents (on/off/auto). With "auto" -option the protection can be controlled by setting individual files -attributes as it disables the file attribute modifications for -the GEMDOS hard disk emulation. - | -
| - | --d, --harddrive <dir> | -
| - | -Emulate harddrive partition(s) with <dir> contents - | -
| - | ---acsi <file> | -
| - | -Emulate an ACSI hard disk with an image <file> - | -
| - | ---ide-master <file> | -
| - | -Emulate an IDE master hard disk with an image <file> - | -
| - | ---ide-slave <file> | -
| - | -Emulate an IDE slave hard disk with an image <file> - | -
| - | ---slowfdc <bool> | -
| - | -slow down FDC emulation (deprecated) - | -
| - | --s, --memsize <x> | -
| - | -Set amount of emulated RAM, x = 1 to 14 MiB, or 0 for 512 -KiB - | -
| - | --t, --tos -<imagefile> | -
| - | -Specify TOS ROM image to use - | -
| - | ---cartridge <imagefile> | -
| - | -Use ROM cartridge image <file> (only works if -GEMDOS HD emulation and extended VDI resolution are -disabled) - | -
| - | ---memstate <file> | -
| - | -Load memory snap-shot <file> - | -
| - | ---cpulevel <x> | -
| - | -Specify CPU (680x0) to use (use x >= 1 with EmuTOS or -TOS >= 2.06 only!) - | -
| - | ---cpuclock <x> | -
| - | -Set the CPU clock (8, 16 or 32 Mhz) - | -
| - | ---compatible <bool> | -
| - | -Use a more compatible but slower 68000 CPU mode - | -
| - | ---machine <x> | -
| - | -select machine type (x = st, ste, tt or falcon) - | -
| - | ---blitter <bool> | -
| - | -Enable blitter emulation (ST only) - | -
| - | ---timer-d <bool> | -
| - | -Patch redundantly high Timer-D frequency set by TOS. This about doubles -Hatari speed as the original Timer-D frequency causes most of the -interrupts. - | -
| - | ---dsp <x> | -
| - | -Falcon DSP emulation (x = none, dummy or emu, Falcon -only) - | -
| - | ---sound <x> | -
| - | -Sound frequency: 6000-50066. "off" disables the sound and speeds up -the emulation. To prevent extra sound artifacts, the frequency should be -selected so that it either matches evenly with the STE/TT/Falcon sound -DMA (6258, 12517, 250033, 50066 Hz) or your sound card frequencies -(11025, 22050, 44100 or 6000...48000 Hz). Check what your sound card -supports. - | -
−j, +−−joystick <port>
+Emulate joystick with cursor keys in +given port (0-5)
+−−joy<port> +<type>
+Set joystick type (none/keys/real) for +given port
+−−printer +<file>
+Enable printer support and write data +to <file>
+−−midi-in +<filename>
+Enable MIDI support and write MIDI data +to <file>
+−−midi-out +<filename>
+Enable MIDI support and read MIDI data +from <file>
+−−rs232-in +<filename>
+Enable serial port support and use +<file> as the input device
+−−rs232-out +<filename>
+Enable serial port support and use +<file> as the output device
-| - | ---sound-buffer-size <x> | -
| - | -SDL's sound buffer size : 10-100, or 0 to use default buffer size. -By default Hatari uses an SDL buffer size of 1024 samples, which -gives approximatively 20-30 ms of sound depending on the chosen sound -frequency. Under some OS or with not fully supported sound card, this -default setting can cause a bigger delay at lower frequency (nearly 0.5 sec). -In that case, you can use this option to force the size of the sound -buffer to a fixed number of milliseconds of sound (using 20 is often -a good choice if you have such problems). Most users will not need this option. - | -
−−disk-a +<file>
+Set disk image for floppy drive A
+−−disk-b +<file>
+Set disk image for floppy drive B
+−−protect-floppy +<x>
+Write protect floppy image contents +(on/off/auto). With "auto" option write protection is according to +the disk image file attributes.
+−−protect-hd +<x>
+Write protect harddrive <dir> +contents (on/off/auto). With "auto" option the protection can be +controlled by setting individual files attributes as it disables +the file attribute modifications for the GEMDOS hard disk +emulation.
+−−gemdos-case <x>
+Specify whether new dir/filenames are forced to be +in upper or lower case with the GEMDOS HD emulation. Off by default. +
+−d, −−harddrive +<dir>
+Emulate harddrive partition(s) with +<dir> contents. If directory contains only single letter +(C-Z) subdirectories, each of these subdirectories will be treated +as a separate partition, otherwise the given directory itself will +be assigned to drive "C:". In the multiple partition case, the +letters used as the subdirectory names will determine to which +drives/partitions they’re assigned.
+−−acsi +<file>
+Emulate an ACSI hard disk with an image +<file>
+−−ide−master +<file>
+Emulate an IDE master hard disk with an +image <file>
+−−ide−slave +<file>
+Emulate an IDE slave hard disk with an +image <file>
+−−fastfdc +<bool>
+speed up FDC emulation (can cause +incompatibilities)
++−−memstate <file>
+Load memory snap-shot <file>
+−s, −−memsize +<x>
+Set amount of emulated RAM, x = 1 to 14 +MiB, or 0 for 512 KiB
+ +−t, +−−tos <imagefile>
+Specify TOS ROM image to use
+−−patch-tos +<bool>
+Use this option to enable/disable TOS +ROM patching. Experts only! Leave this enabled unless you know what +you are doing!
+−−cartridge +<imagefile>
+Use ROM cartridge image <file> +(only works if GEMDOS HD emulation and extended VDI resolution are +disabled)
++−−cpulevel <x>
+Specify CPU (680x0) to use (use x >= +1 with EmuTOS or TOS >= 2.06 only!)
+−−cpuclock +<x>
+Set the CPU clock (8, 16 or 32 Mhz)
+−−compatible +<bool>
+Use a more compatible, but slower 68000 +CPU mode with better prefetch accuracy and cycle counting
++−−machine <x>
+Select machine type (x = st, ste, tt or +falcon)
+−−blitter +<bool>
+Enable blitter emulation (ST only)
+−−dsp <x>
+Falcon DSP emulation (x = none, dummy +or emu, Falcon only)
+−−timer-d +<bool>
+Patch redundantly high Timer-D +frequency set by TOS. This about doubles Hatari speed (for ST/e +emulation) as the original Timer-D frequency causes most of the +interrupts.
+−−fast-boot +<bool>
+Patch TOS and initialize the so-called +"memvalid" system variables to by-pass the memory test of TOS, so +that the system boots faster.
+−−rtc +<bool>
+Enable real-time clock
+ +−−mic +<bool>
+Enable/disable (Falcon only) +microphone
+−−sound +<x>
+Sound frequency: 6000-50066. "off" +disables the sound and speeds up the emulation. To prevent extra +sound artifacts, the frequency should be selected so that it either +matches evenly with the STE/TT/Falcon sound DMA (6258, 12517, +250033, 50066 Hz) or your sound card frequencies (11025, 22050, +44100 or 6000...48000 Hz). Check what your sound card supports.
+−−sound-buffer-size +<x>
+SDL’s sound buffer size: 10-100, +or 0 to use default buffer size. By default Hatari uses an SDL +buffer size of 1024 samples, which gives approximatively 20-30 ms +of sound depending on the chosen sound frequency. Under some OS or +with not fully supported sound card, this default setting can cause +a bigger delay at lower frequency (nearly 0.5 sec). In that case, +you can use this option to force the size of the sound buffer to a +fixed number of milliseconds of sound (using 20 is often a good +choice if you have such problems). Most users will not need this +option.
+−−sound-sync +<bool>
+The emulation rate is nudged by +100 or
+0 or -100 micro-seconds on occasion. This prevents the sound buffer
+from overflowing (long latency and lost samples) or underflowing
+(short latency and repeated samples). The emulation rate smoothly
+deviates by a maximum of 0.58% until synchronized, while the
+emulator continuously generates every sound sample and the crystal
+controlled sound system consumes every sample.
+(on|off, off=default)
−−ym-mixing +<x>
+Select a method for mixing the three +YM2149 voice volumes together. "model" uses a mathematical model of +the YM voices, "table" uses a lookup table of audio output voltage +values measured on STF and "linear" just averages the 3 YM +voices.
-| - | --k, --keymap -<file> | -
| - | -load keyboard mapping from <file> - | -
| - | --D, --debug | -
| - | -Toggle whether CPU exceptions invoke the debugger - | -
| - | ---bios-intercept | -
| - | -Enable Bios/XBios interception - | -
| - | ---trace <trace1,...> | -
| - | -Activate debug traces, see --trace help for available tracing options - | -
| - | ---trace-file <file> | -
| - | -Save trace output to <file> (default=stderr) - | -
| - | ---parse <file> | -
| - | -Parse/execute debugger commands from <file> - | -
| - | ---control-socket <file> | -
| - | -Hatari reads options from given socket at run-time - | -
| - | ---log-file <file> | -
| - | -Save log output to <file> (default=stderr) - | -
| - | ---log-level <x> | -
| - | -Log output level (x=debug/todo/info/warn/error/fatal) - | -
| - | ---alert-level <x> | -
| - | -Show dialog for log messages above given level - | -
| - | ---run-vbls <x> | -
| - | -Exit after X VBLs - | -
−D, +−−debug
+Toggle whether CPU exceptions invoke +the debugger
+−−bios-intercept
+Toggle Bios/XBios call interception needed for +Bios/XBios call tracing. Allows Atari programs to modify Hatari state +through XBios 255 calls which are processed as Hatari commandline +arguments. Atari printscreen call takes also Hatari screenshot.
+−−conout <device>
+Enable console (xconout vector functions) output +redirection for given <device> to host terminal. Device 2 is for +the (CON:) VT52 console, which vector function catches also EmuTOS panic +messages and MiNT console output, not just normal BIOS console output.
+−−disasm <x>
+Set disassembly options. 'uae' and 'ext' select +the dissasembly engine to use, bitmask sets output options for the +external disassembly engine and 'help' lists them.
+−−natfeats <bool>
+Enable/disable (basic) Native Features support. +E.g. EmuTOS uses it for debug output.
+−−trace +<trace1,...>
+Activate debug traces, see +−−trace help for available tracing options
+−−trace-file +<file>
+Save trace output to <file> +(default=stderr)
+−−parse +<file>
+Parse/execute debugger commands from +<file>
+−−saveconfig
+Save Hatari configuration and exit. +Hatari UI needs Hatari configuration file to start, this can be +used to create it automatically.
+−−no-parachute
+Disable SDL parachute to get Hatari +core dumps. SDL parachute is enabled by default to restore video +mode in case Hatari terminates abnormally while using non-standard +screen resolution.
+−−control-socket +<file>
+Hatari reads options from given socket +at run-time
+−−log-file +<file>
+Save log output to <file> +(default=stderr)
+−−log-level +<x>
+Log output level +(x=debug/todo/info/warn/error/fatal)
+−−alert-level +<x>
+Show dialog for log messages above +given level
+−−run-vbls +<x>
+Exit after X VBLs
Type hatari --help to list all the command line options supported by a given version of Hatari.
-Once you've started Hatari succesfully, you can use the emulator as an almost complete Atari ST computer system.
-Press F12 to enter the GUI. Navigate it with the mouse. The GUI is rather self explanatory.
-
+
@@ -1549,10 +846,11 @@ changes that you have made.
-
+
@@ -1560,23 +858,25 @@ changes that you have made. or folder.
- To enter a folder or choose a file, simply click on the entry in the main box - of the dialog. You can use the arrows at the right, the cursor up and down - keys and the page up and down keys to navigate through the list. + To enter a folder or choose a file, simply click on the entry in the + main box of the dialog. To navigate in the file list, you can use the + scrollbar on the right with mouse, or use keyboard up + down arrow, + page up + down, Home and End keys.
You can use the three buttons in the upper right corner for additional folder - navigation. Use the button to go up one level - in the directory tree. Use the button to return - to your home directory. The button can be used + navigation. Click the button to go up one level + in the directory tree. Click the button to return + to your home directory. The button can be clicked to go to the root directory of the file system.
-
+
@@ -1610,7 +910,7 @@ changes that you have made.
some more advanced hardware features. There are not that many demos or
games that really require an STE but since most normal ST games/demos also
work with an STE, it's normally safe to always work in STE mode.
-
+
TT and Falcon are more advanced, but they are not as compatible to the ST as
the STE was. Therefore many old games and demos do not work with these machine
types anymore. There were only very few programs that were made for the TT
@@ -1661,17 +961,18 @@ changes that you have made.
--machine command line option.
+
This dialog can be used to choose which floppy disks should be emulated in the disk drives. You can use most standard Atari ST disk image files. You may select and browse also zipped disk images. See the chapter - "Floppy disk images" for details. + "Floppy disk images" for details.
Click on the button next to the
@@ -1689,15 +990,16 @@ insert the second disk of a two disk gam
Some games then use the second drive automatically.
In the case that a game is not able to find the disk in the second drive,
you have to insert the second disk in drive A: manually when prompted.
-
+
NOTE: This option only works properly if the file name of the
first disks ends with an 'a' before the extension and the second disk name
ends with a 'b'.
- Select if you want to use slow FDC (Floppy Disk Controller) emulation. - "Slow floppy access" is normally not required, except for some few - slideshows / intros which run too fast without this option. + Select if you want to use fast FDC (Floppy Disk Controller) emulation. + "Fast floppy access" will speed up disk accesses, but this could give + some incompatibilities with some programs that expect correct delays. + (some games/demos don't expect data to be read too fast from the disk)
You can choose if you want Hatari to write-protect your disks. Atari ST virii @@ -1707,7 +1009,8 @@ ends with a 'b'.
+
@@ -1732,10 +1035,11 @@ ends with a 'b'.
-
+
@@ -1763,10 +1067,11 @@ ends with a 'b'.
-
+
You can select the amount of RAM for the emulated ST here. Only @@ -1785,10 +1090,11 @@ different versions of Hatari. E.q. if yo cannot load your old memory snapshots back.
-
+
Here you can select the TOS image to use. Click on
- In this dialog, you can configure the emulated joysticks.
@@ -1852,11 +1159,11 @@ certain games. In some other games, it g
See also the chapter "Emulated Joystick" for details.
@@ -1871,7 +1178,7 @@ GUI - the Atari monitor dialog">
switch to ST medium resolution, you will get a TV-like screen rendering
which is a little bit faster but darker compared to the normal "RGB"
monitor mode. Switching between mono and a color monitor acts like a monitor
- switch on a real ST - so beware, this will reboot your emulated system!
@@ -1920,29 +1226,43 @@ on your screen.
a fast computer. When selecting 1, 2 or 4, drawing of corresponding number
of frames will be skipped after each frame actually shown by Hatari.
Select "Auto" to let the emulator to decide whether, and
- how many frames will be skipped.
- "Statusbar" toggles the statusbar at the bottom of the screen.
- The statusbar shows the floppy drive LEDs, the current frameskip value,
- the machine type including TOS version and memory size, and whether
- recording is currently active.
+Indicators that you can have on the Hatari window:
+"Keep desktop resolution" option will use your desktop resolution
+for fullscreen to avoid issues related to resolution switching,
+especially on LCD monitors (they're slow). If this isn't enabled,
+values from the "Max zoomed win" option are used in selecting
+a suitable resolution.
-"Max zoomed" option controls up to which size Hatari tries to scale
+"Max zoomed win" option controls up to which size Hatari tries to scale
the Atari resolutions and how much of the borders (enabled in Atari
-Monitor dialog) will be shown. There are several limitations in
-this:
+Monitor dialog) will be shown. Note that there are several limitations
+in this and the "Keep desktop resolution" option, partly because Hatari
+has different implementations for different video modes:
The Joystick Dialog
+The Joystick Dialog
-
+
The Atari Monitor Dialog
+The Atari Monitor Dialog
-
+
+ switch on a real ST - so beware, this will reboot your emulated system!
In TT mode, you can only choose between TT-high resolution ("Mono")
and normal modes (select one of the other monitor types).
Finally the Falcon mode supports all four types of monitors. Note that most
@@ -1890,19 +1197,18 @@ Extended VDI resolutions will emulate a
card in the emulated ST which give you larger resolutions with a higher
colordepth for GEM. Select a resolution and color depth. Check to
activate. It will disable all other video options mentioned above.
-Uncheck to get back to a normal ST behaviour.
+Uncheck to get back to a normal ST behaviour.
Note: Using an extended resolution will only work with GEM
conformant applications. 99% of all games and demos will not run if you
activate any extended resolution here.
The Hatari
-Screen Dialog
+The Hatari Screen Dialog
-
+
+ how many frames will be skipped.
Note: The frameskip option also affects the frame rate of the
screen animation recording!
+
+
Giving "-z 2" option on command line will reset max zoomed size to @@ -1963,16 +1283,18 @@ not be enabled on very slow computers.
Click the button to create a screenshot in PNG (or BMP) format to the current working directory or click the button to -record an AVI format video of Hatari screen (and audio) output. You -can opt to record new movie frames only when the screen content really -changed. +record an AVI format video of Hatari screen (and audio) output. +
++Selecting "Crop statusbar" option will leave statusbar out from +the screenshots and recorded videos.
- -
+
Here you can select the keyboard mapping to use. Two different mappings @@ -2001,15 +1323,19 @@ changed.
-
+
Here you can control the sound subsystem.
-Check if you want emulated sound at all. Emulation is faster if +
Check "Enabled" if you want emulated sound at all. Emulation is faster if sound emulation is turned off.
+If you experiment latency issues with your OS audio's output, you +can check the "Synchronize" option to adjust Hatari's video emulation to match +your OS audio.
Nine frequencies from low to high quality are available. Experiment a little bit to find out which fits best for your setup. @@ -2019,6 +1345,12 @@ sound emulation is turned off.
the STE/TT/Falcon sound DMA.+YM voices volume mixing "ST table" method uses a lookup table of audio output +voltage values measured on STF, "Math model" uses a complex model to mix the +3 YM voices and "Linear" just averages the 3 YM voices. Use "ST table" or "Math model" +for accurate sound's emulation. +
+You can select to record a piece of sound here. Use the button to choose a file. The file name extension that you use (.WAV or .YM) determines in which format @@ -2028,20 +1360,21 @@ sound emulation is turned off.
-
+
Check the first checkmark to enable experimental printer support. -See the Emulated printer section for +
Check the first checkmark to enable printer support. +See the Emulated printer section for details.
As Hatari currently only supports printing to file, click on to select the file to print to. You can enter a new filename as well.
-Check the second checkmark to enable experimental RS232 support. +
Check the second checkmark to enable RS232 support. The RS232 device is configured according to the settings of the emulated RS232 of the Atari ST. This means Hatari will automatically use baudrate and handshaking as configured for the @@ -2050,7 +1383,7 @@ emulated ST.
device files for serial input and output. On Linux a good choice is /dev/ttyS0 or /dev/ttyS1. -Check the third checkmark to enable experimental MIDI support. +
Check the third checkmark to enable MIDI support. Click on to select a suitable MIDI device files for MIDI input and output.
midi-linux.txt file explains how to @@ -2061,91 +1394,92 @@ Hatari instances.
-While the emulator is running, you can activate or toggle various features via Hatari keyboard shortcuts. Below are listed the default shortcut key bindings:
-| Shortcut | -Purpose | +Shortcut | +Purpose |
|---|---|---|---|
| ALTGR+a | -record animation | +ALTGR+a | +record animation |
| ALTGR+g | -grab a screenshot | +ALTGR+g | +grab a screenshot |
| ALTGR+i | -boss key: leave full screen mode, pause Hatari -and iconify its window | +ALTGR+i | +boss key: leave full screen mode, pause Hatari + and iconify its window |
| ALTGR+j | -toggle joystick emulation via cursor keys -on/off between ports 0 and 1 | +ALTGR+j | +toggle joystick emulation via cursor keys + on/off between ports 0 and 1 |
| ALTGR+m | -(un-)lock the mouse into the window | +ALTGR+m | +(un-)lock the mouse into the window |
| ALTGR+r | -(warm) reset the ST | +ALTGR+r | +(warm) reset the ST |
| ALTGR+c | -coldreset the ST (same as the original power -switch) | +ALTGR+c | +coldreset the ST (same as the original power switch) |
| ALTGR+d | -open dialog to select/change disk A | +ALTGR+d | +open dialog to select/change disk A |
| ALTGR+s | -enable/disable sound | +ALTGR+s | +enable/disable sound |
| ALTGR+q | -quit the emulator | +ALTGR+q | +quit the emulator |
| ALTGR+x | -toggle normal speed/fast forward | +ALTGR+x | +toggle normal speed/fast forward |
| ALTGR+y | -enable/disable sound recording | +ALTGR+y | +enable/disable sound recording |
| ALTGR+k | -save memory snapshot | +ALTGR+k | +save memory snapshot |
| ALTGR+l | -load memory snapshot | +ALTGR+l | +load memory snapshot |
| ALTGR+f or F11 | -toggle between fullscreen and windowed mode | +ALTGR+f or F11 | +toggle between fullscreen and windowed mode |
| ALTGR+o or F12 | -activate the options GUI | +ALTGR+o or F12 | +activate the options GUI |
| PAUSE | -pause emulation | +PAUSE | +pause emulation |
| AltGr+PAUSE | -invoke the internal Hatari debugger | +AltGr+PAUSE | +invoke the internal Hatari debugger |
All other keys on the keyboard act as the normal Atari ST keys so pressing SPACE on your PC will result in an emulated press of the SPACE key on the ST. The following keys have special meanings:
-| Key | -Meaning | +Key | +Meaning |
|---|---|---|---|
| Alt | -will act as the ST's ALTERNATE key | +Alt | +will act as the ST's ALTERNATE key |
| left CTRL | -will act as the ST's CONTROL key | +left CTRL | +will act as the ST's CONTROL key |
| Print Screen | -will emulate the ST's HELP key | +Print Screen | +will emulate the ST's HELP key |
| Scroll Lock | -will emulate the ST's UNDO key | +Scroll Lock | +will emulate the ST's UNDO key |
| Page Up | -will emulate the ST's ( key in the keypad | +Page Up | +will emulate the ST's ( key in the keypad |
| Page Down | -will emulate the ST's ) in the keypad | +Page Down | +will emulate the ST's ) in the keypad |
For obvious reasons your PC mouse will act as the emulated Atari ST mouse. In fullscreen mode it will act as expected, directly controlling the ST mouse pointer.
-However it is a little bit different in windowed mode. To make the -mouse work there as expected you need to grab it first or lock it into -the Hatari window. Do this by pressing the ALTGR+m +
However it is a little bit different in windowed mode as +mouse cursor positions between host and emulated Atari can get +out of sync. This can be worked around by constraining the mouse +to the Hatari window. Pressing the ALTGR+m hotkey combination or starting Hatari with the ---grab command line option. +--grab command line option +grabs the mouse i.e. locks its movements to the Hatari window. Press the shortcut key (again) to go back to normal mouse behaviour which allows you to move mouse outside outside the Hatari window while Hatari is up and running. Note: pausing the emulation will also (temporarily) release the mouse grab.
Mouse scrollwheel will act as cursor up and down keys.
-The Atari ST joysticks are emulated ofcourse allowing you to play your favourite games with Hatari.
@@ -2245,7 +1584,7 @@ cursorkeys in this mode as long as you p along with the cursorkeys. You can also configure these keys from the joystick options. -Hatari emulates all screen modes of the original machine.
@@ -2262,11 +1601,11 @@ into your Mega ST.
Make sure to disable extended VDI modes for playing games as 99% of all ST games will not be able to make use of higher resolutions.
-Due to the fact that printer handling is very different between Unix -style machines and the Atari ST, emulation -of the printer is achieved by writing all printer output to a file.
+Due to the fact that printer handling is different on Atari and +current machines, emulation of the printer is achieved by writing all +printer output to a file.
The file will contain a sequence of data, the same that would appear on the data pins of the Atari ST printer port. That would include control characters and commands for graphic @@ -2276,13 +1615,13 @@ in a messy data dump in the printer outp do not format the output for a specific printer. The file contents can be used with your favourite text editor for further processing and printing to a real printer.
-To get real direct printing out of Hatari on a PostScript printer,
-you may set up a GDOS printer with a PostScript driver on the emulated
-Atari and set your printer device file as Hatari's printer output.
-NOTE: This has not been tested yet and the Hatari team cannot
-guarantee that it will work.
To get real direct printing out of Hatari you may set up a suitable
+(e.g. PostScript) GDOS or NVDI printer driver on the emulated Atari and
+set your printer device file as Hatari's printer output.
+NOTE: If the driver doesn't match or there's some other problem,
+this can cause your printer to print out hundreds of pages of garbage.
Serial communications in Hatari is designed to directly use a serial port on your PC.
@@ -2292,7 +1631,7 @@ the communication parameters like baudra software. Hatari will do the rest and handle the serial input and output for you. -Hatari does not use floppy disks directly but disk images due to differences between the floppy disk controllers of the ST and the PC. @@ -2363,7 +1702,7 @@ your highscores and savegames are lost i a zipped disk image.
-Hatari supports three ways of emulating Atari hard drives: The low-level @@ -2378,28 +1717,25 @@ while the emulator is running.
On a 32-bit host system, the size of a hard disk image is limited to 2 GB. -On 64-bit host systems, bigger images might be possible but the support for -bigger images is not tested very well yet. +On 64-bit host systems, bigger images might be possible but the support +for bigger images is not tested very well yet. How large partition sizes +are supported inside the hard disk (images) depends on the TOS version. +TOS 1.0x supports up to 256MB partitions and TOS 4.0x up to 1GB ones.
-With the GEMDOS based drive emulation, you can easily "mount" a -folder from the host file system to a drive of the emulated Atari. To -use the GEMDOS based drive emulation, you should use a folder on your -hard disk that only contains files and folders with valid TOS -filenames i.e. file and folders names shouldn't contain invalid GEMDOS -filename characters and their length shouldn't exceed the 8+3 file name -length limit. +folder from the host file system to a drive of the emulated Atari.
-If you provide --harddisk option -a directory containing only single letter subdirectories, each of -these subdirectories will be treated as a separate partition, otherwise -the given directory itself will be assigned to drive "C:". In the -multiple partition case, the letters used as the subdirectory names -will determine to which drives/partitions they're assigned. +If you provide Hatari a directory containing only single letter (C-Z) +subdirectories, each of these subdirectories will be treated as a +separate partition, otherwise the given directory itself will be +assigned to drive "C:". In the multiple partition case, the letters +used as the subdirectory names will determine to which +drives/partitions they're assigned.
GEMDOS drive emulation is an easy way to share files between the @@ -2408,18 +1744,25 @@ limitations which are due to the way the implemented:
To use the ACSI hard disk emulation, you need a hard disk image file with a pre-installed HD driver in it. You can try to get an image of @@ -2458,7 +1801,7 @@ After installing the hard disk driver to HINSTALL.PRG, you can boot directly from the hard disk image.
-
As the IDE disk format (little endian) differs from the ACSI disk format @@ -2490,7 +1833,7 @@ the Cecile hard disk driver to the image Click the "Installer" button and save the Cecile driver to the 1st partition on "Hatari IDE disk". If you want to also use your HD image in ST/STE mode, you need to get and install AHDI 6 driver on it -instead (see ASCI hard disk +instead (see ASCI hard disk emulation section).
@@ -2499,8 +1842,7 @@ with the --ide
-Moving files to and from Atari hard disk images can be done either through GEMDOS partitions (host directories mounted inside @@ -2514,8 +1856,7 @@ a GEMDOS partition i.e. such to be befor and still to be able to access all the IDE/ACSI partitions, you need to use HD Driver.
-Uwe Seimet's HD
Driver works fine with both the Hatari GEMDOS partitions and normal
@@ -2550,8 +1891,7 @@ its AUTO folder, like this: "
-
If you want to access the harddisk image partitions also outside
@@ -2633,7 +1973,8 @@ the disk image from Hatari:
# losetup -d $loop
-
Hatari has a built-in debugging interface which can be used for
@@ -2643,21 +1984,32 @@ key combination.
-If you start Hatari with the "-D" command line option, m68k
-exceptions will automatically invoke the debugger. You can
+If you start Hatari with the "-D" command line option, certain m68k
+exceptions will automatically drop Hatari into the debugger. You can
toggle this also later from the debugger with the "setopt -D"
command.
+To run debugger commands at Hatari startup, one can use the "--parse
+<file>" command line option. This is useful e.g. for debugging
+TOS or some demo startup code, or if you always want to use some
+specific debugger setup (breakpoints etc).
+
The debugger uses Hatari's parent console window, so make sure you run
Hatari from the command line when you want to use the debugger. On
-Linux you can add for example an icon to your desktop that runs: xterm -T "Hatari debug window" -e hatari.
+Linux you can add for example an icon to your desktop that does it
+with something like this (replace "xterm" with your favorite terminal
+program):
At the debugger prompt, type "help" to get a list of all
@@ -2667,10 +2019,10 @@ the available commands and their shortcu
Generic commands:
cd ( ) : change directory
evaluate ( e) : evaluate an expression
- exec ( ) : execute a shell command
help ( h) : print help
+ history (hi) : show last CPU & DSP PC values & executed instructions
info ( i) : show machine/OS information
- lock ( ) : lock info to show on entering debugger
+ lock ( ) : specify information to show on entering the debugger
logfile ( f) : open or close log file
parse ( p) : get debugger commands from file
setopt ( o) : set Hatari command line and debugger options
@@ -2683,12 +2035,15 @@ 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 to memory
loadbin ( l) : load a file into memory
- savebin ( s) : save memory to a file
+ savebin ( ) : save memory to a file
symbols ( ) : load CPU symbols & their addresses
+ step ( s) : single-step CPU
+ next ( n) : step CPU, proceeding through subroutine calls
cont ( c) : continue emulation / CPU single-stepping
DSP commands:
@@ -2697,53 +2052,76 @@ DSP commands:
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, proceeding through subroutine calls
dspcont (dc) : continue emulation / DSP single-stepping
+
+
-When entering numbers to the debugger commands in other number bases
+After writing (with TAB completion) one of the above command names,
+pressing TAB will (for most commands) show all the available subcommands.
+
+If you want to give numbers in other number bases
than the default/selected one, they need to be prefixed with a
character indicating this. For decimals this prefix is "#" (#15),
for hexadecimals "$" ($F), and for binary values it's "%" (%1111).
-By default the debugger expects all numbers without a prefix to be
+
+By default debugger expects all numbers without a prefix to be
decimals, but you can change the default number base with the "setopt"
command, just give it the desired default number base (bin/dec/hex).
+When using the hexadecimal number base, remember still to prefix
+hexadecimal numbers with '$' if they could be confused with register
+names (a0-7, d0-7)! Otherwise results from expressions and
+conditional breakpoints can be unexpected.
-Instead of a number, you can also use an expression, by surrounding
-it with quotes (""). An expression can contain calculations with
-register and symbol values in addition to numbers. For example to
-give a sum of A0 and D0 register values to a command, use "a0+d0".
+Instead of a number, you can also use an arithmetic expression, by
+surrounding it with quotes (""). An expression can contain
+calculations with CPU and DSP register, symbol and Hatari variable
+values in addition to numbers. For example to give a sum of A0 and
+D0 register values to a command, use "a0+d0".
-Note that within expressions parenthesis are used to change
-the order of precendence, they cannot be used for
-indicating indirect addressing like with conditional breakpoints
-(explained below). Even when using expressions within conditional
-breakpoints.
-And when using the hexadecimal number base, remember still to prefix
-with '$' hexadesimal numbers that can be confused with register names
-(a0-7, d0-7), otherwise results from expressions and conditional
-breakpoints can be quite surprising.
+Within arithmetic expressions parenthesis are used both to change
+the order of precendence and to indicate indirect addressing.
+Unlike with conditional breakpoint expressions (explained below), you
+cannot give size for the indirect addressing, a long value is always
+read from the RAM address given within parenthesis. For example to
+get a long value pointed by stack pointer + 2, use "(a7+2)".
-Expressions are always evaluated before being given to a command.
-Expressions don't need to be quoted for the "evaluate" or "address"
-commands as those always interpret their results as expressions.
+Values of arithmetic expressions are always evaluated before being
+given to a command. Except for "evaluate" and "address" commands,
+they always need to be marked with quotes (""). Besides arithmetics,
+this can be used also to give symbol/register/variable values to
+commands that don't otherwise interpret them. If command complains
+that it didn't recognize e.g. a register name, just put it to quotes
+and it will be "evaluated" before being given to the command.
-With command argument completion (see build
-notes), result from last "evaluate" command can inserted by
-typing '$' and pressing TAB.
+With command argument completion (see build
+notes), result from the last "evaluate" command can be inserted
+by typing '$' and pressing TAB.
In the beginning, probably the most interesting commands are "m" and "d"
@@ -2764,85 +2142,175 @@ Usage: d [start address-[end address]]
position or from current PC if no last position is available.
+Both commands accept in addition to numeric addresses also register
+and symbol names, like in above example. If you don't specify an
+address, the commands continue showing from an address that comes
+after the previously shown data. "disasm" command default address
+will be reseted to PC address everytime you re-enter the debugger.
+
+Use "setopt --disasm help" if you want to set options controlling
+the disassembly output.
+
You can use the "info" command to see state of specific sets of HW
-registers ("info videl") or Atari OS structures ("info basepage").
+registers (e.g. "info videl") and Atari OS structures (e.g. "info gemdos").
+
+By using the "lock" command, you can ask Hatari to show specific
+information whenever you enter the debugger / hit a breakpoint. For
+example to see disassembly from current PC address, use "lock disasm".
-By using the "lock" command, you can ask Hatari to show above kind of
-information whenever you enter the debugger ("lock disasm"). With the
-"regaddr" subcommand, it can show also disassembly or memory dump of
-an address pointed by a given register ("lock regaddr disasm a0"). Of
-the DSP registers, only Rx ones are valid for this subcommand. To
-disable showing of this extra information, use "lock default".
+With the "regaddr" subcommand, you see disassembly or memory
+dump of an address pointed by a given register ("lock regaddr disasm
+a0"). Of the DSP registers, only Rx ones are valid for this
+subcommand.
+"file" subcommand can be used to get (arbitrary number of) commands
+parsed and executed from a given debugger input file whenever debugger
+is entered. With this you can output any information you need:
+
-You can load symbol name/address information from a file to the
-debugger with the "symbols" command (and with "dspsymbols" for DSP).
-These symbolic names can be used in expressions and all breakpoints.
-They also show up in the "disasm" command output.
+To disable showing of this extra information, use "lock default".
+Without arguments "lock" command will show the available options
+(like the "info" command does).
The symbols file format is following:
+You can load debugging symbols to the debugger with the "symbols"
+command (and with "dspsymbols" for DSP). These symbolic names can be
+used in arithmetic expressions and conditional breakpoint expressions.
+They also show up in the "disasm" command output and you can trace
+calls to them with "trace cpu_symbols" (and DSP symbols with "trace
+dsp_symbols").
+
+If you're using GEMDOS HD emulation, and your program contains symbol
+table in DRI/GST format, you can load its symbol names/addresses to
+the debugger with the following command, after program has been loaded
+to the memory by TOS (see setting
+breakpoint at program startup):
+
+
+
+The options you need to add suitable symbol table to your programs,
+depend on which toolchain you use to build it:
+ You can view the generated symbols (and convert them to debugger
+ASCII format) with tool installed with Hatari:
+If the program isn't run from a GEMDOS HD emulated drive, but from a
+cartridge, floppy or HD image, you need to have the corresponding
+program also as normal host file which location you can give to the
+debugger:
+
+If Hatari complains that your program doesn't have DRI/GST format
+symbol table, or its symbols are in some other format, and you
+cannot re-compile it to have them, you have two options:
+ ASCII symbols file format is following:
-Where 'T' means text (code), 'D' means data and 'B' BSS section type
-of address. The symbol hexadecimal address, type letter and name are
-separated by white space. Empty lines and lines starting with '#'
-(comments) are ignored.
+Where 'T' means text (code), 'D' means data and 'B' means BSS section
+type of address. The hexadecimal address, address type letter and the
+symbol name are separated by white space. Empty lines and lines
+starting with '#' (comments) are ignored.
-AHCC C-compiler can provide a symbol file suitable for this with its
-"-n 'nm' list" option (not enabled by default). If you're reverse
-engineering some code, you could just create your own symbols file to
-help in debugging it later.
+Debugger will automatically "relocate" the symbol addresses when it
+loads them from a program binary, but with ASCII symbol files you need
+to give the relocation offset(s) separately, unless the symbol names
+are for fixed adresses (like is the case e.g. with EmuTOS):
-If you're debugging normal TOS/GEM programs instead of code loaded
-into fixed address (like EmuTOS), you can use the "info basepage"
-command to find out the text segment address to which the program code
-has been loaded into, and then load symbols so that their addresses
-are offset by the text segment address:
-
+If you're interested only about code symbols, you can leave DATA and
+BSS offsets out (the values of the above virtual debugger variables
+like TEXT come from the currently loaded program's basepage, they're
+set after the program is loaded by TOS, see "info basepage" output).
+
There are two ways to specify breakpoints for Hatari. First, there are
@@ -2851,168 +2319,1401 @@ program counter hits a given address. Us
to create them, for example:
-(Address breakpoints are just wrappers for conditional breakpoints so
-you need to use "b" command to remove or list them.)
+Note that address breakpoints are just wrappers for conditional
+breakpoints so you need to use "b" command to remove or list them.
Then there are the conditional breakpoints which can handle much more
-complex break conditions; they can track changes to register and
-memory values with bitmasks, include multiple conditions for
-triggering a breakpoint and so on. Use "b" (or "db" for the DSP)
-to manage them. "b help" explains the syntax:
+complex break condition expressions; they can track changes to
+register and memory values with bitmasks, include multiple conditions
+for triggering a breakpoint and so on. Use "b" (or "db" for the DSP)
+to manage them.
Help explains the general syntax:
+Unless you give breakpoint one of the pre-defined subcommands ('all',
+'help'), index for a breakpoint to remove or no arguments (to list
+breakpoints), the arguments are interpreted as a new breakpoint
+definition.
+
+Each conditional breakpoint can have (currently up to 4) conditions
+which are separated by "&&". All of the breakpoint's
+conditions need to be true for a breakpoint to trigger.
+
+Normally when a breakpoint is triggered, emulation is stopped and you
+get to the debugger. Breakpoint options can be used to affect what
+happens when a breakpoint is triggered. These options are given after
+the conditions and are prefixed with ':'.
+
+Note: you can give multiple options for conditional breakpoints, but
+for address breakpoints you can give only one these options. And
+"file" option is supported only for conditional breakpoints.
+
+"b help" explains very briefly the breakpoint condition syntax:
+
+For CPU breakpoints, mode is the address width; it can be byte ("b"),
+word ("w") or long ("l", default). For DSP breakpoints, mode specifies
+the address space: "P", "X" or "Y". Note that on DSP only R0-R7
+registers can be used for memory addressing. For example;
+
If the value is in parenthesis like in '($ff820)' or '(a0)', then the
used value will be read from the memory address pointed by it. Note
-that this value is checked at run-time whereas quoted expressions
-(mentioned above, please read!) are evaluated already when adding a
-breakpoint. For example, to break when value in adress pointed by A0
-matches the value currently in D0, one would use:
+that this conditional breakpoint expression value is checked at
+run-time whereas quoted arithmetic expressions (mentioned in
+Entering arguments
+to debugger commands above) are evaluated already when
+adding a breakpoint. For example, to break when a value in an address
+(later) pointed by A0 matches the value currently in D0, one
+would use:
+If you're interested only on certain bits in the value, you can use
+'&' and a numeric mask on either side of comparison operator to
+mask the coresponding value, like this:
+
-M68k addresses can have byte ("b"), word ("w") or long ("l", default)
-width. DSP addresses belong to different address spaces: "P", "X" or
-"Y". Note that on DSP only R0-R7 registers can be used for memory
-addressing.
+Comparison operators should be familiar and obvious, except for '!'
+which indicates inequality ("is not") comparison. For example:
Examples:
+As a convenience, if the both sides of the comparison are exactly the
+same (i.e. condition is redundant as it's always either true or
+false), the right side of the comparison is replaced with
+its current value. This way you can give something like this:
+ As:
-The debugger supports also setting conditional breakpoints on values
-of some internal Hatari variables (listed by "b help"). For example
-if you want to stop at a specific cycle within a frame (that is, PC
-relative to the current VBL/HBL in cycles), set breakpoints to
-specific "HBL" and "LineCycles" variable values. The "e" command
-can be used to calculate suitable register and variable values.
+That in itself isn't so useful, but for inequality ('!') comparison,
+conditional breakpoint will additionally track and output all further
+changes for the given address/register expression. This can be used
+for example to find out all value changes in a given memory address,
+like this:
+Because tracking breakpoint conditions will print the evaluated
+value when it changes, they're typically used with the trace option
+to track changes e.g. to some IO register.
+
-As a convenience, if the value expressions on both sides of the
-comparison are exactly the same, right side is replaced with its
-current value. For inequality ('!') comparison, conditional breakpoint
-tracks all further changes for the given address/register expression,
-this can be used for example to find out all value changes in a given
-memory address (see examples below).
+In addition to loaded symbols, the debugger supports also setting
+conditional breakpoints on values of some "virtual" variables listed
+by "b help". For example:
-There are also several options that you can use with both breakpoint
-types. ":trace" option will make breakpoint to print out the tracked
-value instead of breaking. This can be useful e.g. when tracking
-changes to some register like in:
+Hint: "info" command "aes", "bios", "gemdos", "vdi" and "xbios"
+subcommands for can be used to list the corresponding OS-call opcodes.
+For example, to see the GEMDOS opcodes, use:
+As the file pointed by the breakpoint ":file" option (see
+Breakpoint options) can contain any
+debugger commands, it can also be used to do automatic "chaining" of
+debugger and breakpoint actions so that after one breakpoint is hit,
+another one is set.
For example if you have these input files:
-":once" option that removes breakpoint after hit can be useful when one
-wants to get out of a loop (when at the instruction that branches back
-to loop start) or just to get to a specific point in code:
+And then start Hatari with the first debugger input file and a GEMDOS
+harddisk directory containing "desktop.inf" file:
-Whereas giving count (like ":2") as option will break only on every
-<count> hit.
+Note: because debugger input files cannot "continue"
+emulation, ":trace" option needs to be used for the breakpoint(s)
+if you want emulation to continue after the breakpoint action(s).
-After analyzing and/or setting new breakpoints, you can continue the
-emulation with the "c" command. You can continue for a given number of
-CPU instructions (or DSP instructions when "dc" is used), or you can
-continue forever (until a breakpoint triggers) if you omit the
-instruction count.
+Hint: It's better to test each input file separate before testing the
+whole chain. Besides the ":file" breakpoint option, these debugger
+input files can be also read with the debugger "file" command, "lock"
+command "file" option and with the Hatari "--parse" command line
+option.
+After analyzing the emulation state and/or setting new breakpoints,
+you can continue the emulation with the "c" command. You can continue
+for a given number of CPU instructions (or DSP instructions when "dc"
+is used), or you can continue forever (until a non-tracing breakpoint
+triggers) if you omit the instruction count.
+
+If you want to continue just to the next instruction, use "s" (step)
+command to continue for exactly one instruction, or "n" (next), if you
+want to skip subroutine calls.
+
-If you want to continue with real-time disassembling, you can enable it
-with "trace cpu_disasm" at the debugger prompt before continuing.
+If you want to continue with real-time disassembling, you can enable
+it with "trace cpu_disasm" (or "trace dsp_disasm" for DSP) at the
+debugger prompt before continuing.
Disable tracing with "trace none" when you enter the debugger again.
-"trace help" (or TAB) can be used to list all the supported trace points.
+"trace help" (or TAB) can be used to list all the (over 40) supported
+traceable things, from HW events to OS functions.
Because Hatari normally emulates things at the hardware level, tracing
-Atari OS functions requires setting additional Hatari options which
-tell it to intercept higher level functionality:
+certain Atari OS Traps requires setting additional Hatari options
+which tell it to intercept this higher level functionality:
-Tracing options can be set even from a program within the emulation
-if you enable Hatari "--bios-intercept" option and call XBios 255 from
-the program with a suitable Hatari command line string.
+Unlike with VDI tracing, AES, BIOS, GEMDOS and XBIOS traces show arguments
+for most of the calls.
+
+Tracing options can be set even from a program within the emulation,
+if you enable the Hatari "--bios-intercept" option and call XBios 255
+from the program with a suitable Hatari command line string.
Note that the trace output file can be set only when Hatari starts,
it cannot be changed from within the debugger (or emulation).
+If tracing isn't possible for the things you'd like to track, you can
+use the OS call opcode breakpoints explained above with the ":trace"
+breakpoint option.
+
-Lastly, the debugger is much nicer to use with the command line
-history, editing and especially with the command, command argument and
-symbol name completion support. If you're building Hatari yourself,
-please make sure that you have the GNU readline development files
-installed (on Debian / Ubuntu these come from the libreadline5-dev
-package). Otherwise this doesn't get enabled when you configure
-Hatari.
+Profiling tells where the emulated code spends most of its (emulated)
+time. It can be used to find out where a program is (apparently)
+stuck, or what are the largest performance bottlenecks for a program.
+
+Profiling is used by first enabling the profiler (use "dp" for DSP):
+
+And profiling will start once you continue the emulation:
+
+When you get back to the debugger, the collected profiling information
+is processed and a summary of in which parts of memory the execution
+happened, and how long it took, is shown:
+
+(DSP RAM will be shown only as single area in profile information.)
+
+When you're back in debugger, you can inspect the collected profile data:
+ For example, to see which memory addresses were executed most
+and what instructions those have at the end of profiling, use:
+Then, to see what the executed code and its costs look like
+around top addresses:
+
+Unlike normal disassembly, "profile addresses" command shows only
+memory addresses which instructions were executed during profiling.
+You get instruction cache misses only when using cycle-accurate 030
+emulation with a Hatari version configured to use WinUAE CPU core.
+
+If you have loaded symbol information, symbol names are shown above
+the corresponding addresses. With the "profile symbols" command you
+get a list of how many times the code execution passed through the
+defined symbol addresses.
+ Profile data accuracy depends on Hatari emulation accuracy.
+Profile data accuracy from most to least accurate when Hatari's
+default emulation options are used is following:
+If you have loaded symbols (see Debug symbols)
+before continuing emulation/profiling, additional caller information
+will be collected for all the code symbol addresses which are called
+as subroutines. This information includes callstack, call counts,
+calling instruction type (subroutine call, branch, return etc), and
+costs for those calls, both including costs for further subroutine
+calls and without them.
+ When debugger is re-entered, current callstack is output before
+profiling information: ("profile stack" command can be used in breakpoints with :noinit
+option to show backtraces during caller profiling.) Other information collected during profiling is shown with
+following command:
+For example, if you don't know all the places from which a certain
+function is called, or in what context a certain interrupt handler can
+be called during the period you're profiling, profile caller
+information will tell you:
+
+(Most "calls" to "dsp_interrupt" were subroutine call returns (=r)
+to it from address 0x155.)
+
+With the execution counts in normal profiling data, caller information
+can actually be used to have complete picture of what exactly the code
+did during profiling. Main/overview work for this analysis is best done
+automatically, by the profiler data post-processor (documented below).
+ Everything about profile data accuracy applies also to caller costs,
+but there are additional things to take into account, mainly because
+profiler cannot determine when exceptions are being handling: It's useful to save the profile data to a file:
+ With the saved profile disassembly (and optional caller information)
+you can more easily investigate what your program did during
+profiling, search symbols & addresses in it, and compare the
+results to profiles you've saved from earlier versions of your code. You may even create your own post-processing tools for
+investigating the profiling data more closely, e.g. to
+find
+CPU/DSP communication bottlenecks. Saved profile data can be post-processed with (Python) script
+installed by Hatari, to: When the data is post-processed, you should always provide
+the post-processor symbols for the profile code! Relying just on the
+symbol in the profile data can cause costs to be asssigned to wrong
+symbol, if symbol's code wasn't called through symbol's own address,
+but by jumping inside its code. If your code is in fixed location, you should tell
+post-processor to handle symbol addresses as absolute (-a): Normal programs are relocated and you should instead give
+the symbols as TEXT (code) section relative ones (-r): If symbols are included to your binary in DRI/GST format, first they
+need to be extracted to the ASCII format
+understood by the post-processor: If there are some extra symbols that you don't want to see
+separately in profiles, because they aren't real functions,
+but e.g. loop labels, you can either remove them manually
+from the ASCII *.sym file, or filter them out with grep:
+ Above post-processor examples just parse + verify the given data
+and produce output like this: To get statistics (-s) and list of top (-t) CPU users in profile,
+add "-st" option: If you want to see also symbol addresses and what is per call
+cost, add -i option:
+ (For cycles the "per call" information is in seconds, not as
+a cost count.) If your profile file contains caller information, you should
+add -p option to see it, as that will also help in detecting symbol
+issues (see Interpreting
+the numbers):
+ Now there's a message telling that some of the calls were ignored as
+based on "call type" they were determined to be actually returns from
+exceptions, not real calls (this is mainly important for callgraph
+generation, discussed below). In addition to accuracy issues mentioned in previous Profiling
+sections, function/symbol level costs have gotchas of their own. The first cost percentage and count columns are sums for all
+the instructions that were in profile data file between
+the indicated symbol's address and the address of the next symbol
+(= "between-symbols" cost). NOTE: If your symbol file doesn't contain addresses
+for all the relevant symbols, results from this can be misleading because
+instructions costs get assigned to whatever symbol's address
+happened to preceed those instructions. And you don't see which
+caller is causing it from caller info or callgraph either, as entry
+point for that time sink lacking a symbol means profiler hadn't
+tracked calls to it... The next two cost percentage and count columns are for subroutine
+calls costs, first one for exclusive and latter for inclusive cost
+i.e. including costs for further subroutine calls. Values are based on
+caller information documented above. Reasons why between-symbol costs, and subroutine call costs can
+differ are following: In the first case, you should check the profile data to find out
+whether there are missing symbols for executed function entry points.
+You can notice function entry points as address gap and/or code
+retrieving arguments from stack, and exit points from RTS instruction. Second case can also be seen from the profile data. Call count
+is same as count for how many times first instruction is executed
+(worst case: large loop on subroutine's first instruction). While subroutine costs should be more accurate and relevant, due to
+code optimizations many of the functions are not called as subroutines
+(on m68k, using JSR/BSR), but just jumped or branced to. Because of
+this, it's useful to compare both subroutine and between-symbols
+costs. One should be able to see from the profile disassembly which
+of the above cases is cause for the discrepancy in the values. NOTE: Before starting to do any serious source
+level optimizations, you should always verify from profile
+data (disassembly) where exactly the costs are in a function, to make
+sure your optimization efforts can actually help the performance. Callgraphs require saved profile data to contain caller information,
+i.e. symbols should have been loaded before starting profiling (normally
+done with "symbols prg" command in Hatari debugger). Separate callgraphs will be created for each of the costs
+(0=calls, 1=instructions, 2=cycles) with the -g option: Callgraphs are saved in GraphViz
+"dot" format. Dot files can be viewed: Produced callgraph will look like this: Interpreting the callgraph: If profile is for larger and more varied amount of code
+(e.g. program startup), the resulting callgraph can be so
+huge it's unreadable. If your code has interrupt handlers, they can get called
+at any point, which can show in callgraph as "explicit" calls
+from the interrupted functions. To get rid of such incorrect
+calls, give interrupt handler names to --ignore-to option: In large callgraph most of the functions aren't really interesting,
+because their contribution to the cost is insignificant. You can
+remove large number of them with --no-leafs and --no-intermediate
+options, they act only on on nodes which costs are below
+given threshold. Leaf nodes are ones which don't have any parents
+and/or children and intermediate ones which have only single parent
+and children (node calling itself is not taken into account).
+
+ Threshold for this is given with the --limit (-l) option. With
+that it typically makes also sense to change the node emphasis
+threshold with --emph-limit (-e) option: If you're not interested in from how many different addresses
+a given function calls another function, use --compact option. If you
+still see multiple calls between two nodes with it, the reason is that
+they happened through different call paths which were removed from
+the callgraph after --compact option was applied: If even this doesn't help, you can remove all nodes below
+the given cost threshold limit with --no-limited option, but this
+often doesn't leave much of a call hiararchy. Instead you may
+consider removing all nodes except for subroutine call ones with
+--only-subroutines option. If you have trouble locating nodes you're specially interested
+about, you can either color them differently with the --mark option,
+or exclude everything else from the callgraph except those nodes and
+their immediate callers & callees, with the --only option: Last option for reading the callgraph is using -k option to
+export the data for use in (Linux) Kcachegrind UI. It generates
+callgraphs on the fly, and just for the area around the function
+you selected, so navigating in callgraph may be easier. It also
+shows the related profile disassembly, which can make verifying
+matters easier:
+Here's a list of some common debugging tasks and how to do them
+with the Hatari debugger:
+Hint: for most of the above commands, one just needs to prefix them with
+"d" (or "dsp" when using full command names) to do similar operation on
+the DSP.
+
+Lastly, the debugger is much nicer to use with the command line
+history, editing and especially the completion support for the
+command, command argument and symbol names.
+
+If you're building Hatari yourself, please make sure that you have the
+GNU readline development files installed (on Debian / Ubuntu these
+come from the libreadline5-dev package). Otherwise the name completion
+and other features don't get enabled when you configure Hatari.
+
ENABLE_TRACING define needs to be set for tracing to work.
By default it should be enabled.
Hatari performance varies between Atari programs, depending on what
features Hatari needs to emulate for them. Less accurate Atari
emulators may be faster as emulation accuracy has a performance
overhead. The operating system and libraries below Hatari can also sometimes
+have a noticeable effect on performance.
+Hatari currently runs best in 16 or 32 bits per pixel color depth
+mode, so try to avoid 24 bits per pixel display modes if possible.
+16-bit mode is fastest.
+
+On OSX, frame skipping, zooming and drive LED options (listed below)
+seem to have a large effect on performance in the windowed mode.
+This is apparently due to issues in the SDL OSX backend and how OSX
+itself composites non-fullscreen window contents. OSX uses always
+32-bit mode.
+
Unless you've disabled compiler optimizations (like GCC's -O2 or -O3
@@ -3022,34 +3723,41 @@ performance. Using GCC -O3 option inste
(5-10%) performance improvements for things (demos) that use very
heavily interrupts.
However, Hatari can be sped up considerably by giving up some
-emulation or emulator accuracy. Most of these options should
-be needed only on slow devices like handhelds.
+emulation or emulator accuracy. Except for DSP, these options
+should be needed only on very slow devices like handhelds. See below.
+
+If nothing else helps, try an earlier Hatari version. More accurate
+emulation or emulator output in newer Hatari versions means that they
+can be slower despite optimizations.
Emulation options have the largest impact on performance.
These options can be changed from the Hatari GUI System dialog and
the emulation needs to be rebooted for any of these changes to take
-an effect!
+an effect! They're enabled by default.
Emulating the Falcon DSP is performance-wise several times more demanding
than emulating the m68k; DSP runs at higher frequency, executes many
instructions for each m68k instruction and emulation isn't as mature
-and optimized. Unless some program needs DSP, none or
+and optimized. Unless some Falcon program needs DSP, none or
dummy DSP emulation mode could be used. Even of the programs
that do use DSP, many use it only for background music and work
fine without the real DSP emulation.
The single largest factor contributing to general Hatari emulation
performance is the handling of interrupts. Enabling Timer-D patching
@@ -3058,7 +3766,15 @@ significantly reduces the number of inte
Atari machine. Using this has adverse effect only for very rare programs.
+While accurate FDC emulation doesn't take that much CPU, it slows down
+floppy image accesses (and Hatari startup) a lot. Only very
+few demos and games require accurate FDC emulation for their copy protection,
+so enabling fast floppy access is fairly safe.
+
After the DSP and interrupts, m68k emulation takes most time.
Disabling the "Slower but more compatible CPU" option will speed up
@@ -3077,24 +3793,24 @@ machine.
-NOTE: Above options may cause some programs not to work correctly.
+NOTE: Above options may cause some programs to work in correctly.
The Hatari Software Compatibility List
-lists programs known to need real real Falcon DSP emulation or Timer-D
-frequency. Disabling "Compatible CPU" option is recommended only as
-a last resort.
+lists programs known to need real real Falcon DSP emulation, Timer-D
+frequency or accurate FDC timings. Disabling "Compatible CPU" option
+is recommended only as a last resort.
-Emulator options don't have as large effect on performance as
+Emulator options don't usually have as large effect on performance as
emulation options, but they don't affect the emulated programs at all,
just the quality of the emulation "output". These options can also
be toggled at run-time without rebooting the emulation.
Internal Hatari sound handling and the SDL_mixer sound thread
libALSA sound processing can account up to 1/3 of the Hatari CPU usage
@@ -3105,22 +3821,24 @@ in Hatari as this can significantly redu
interrupts.
Screen rendering can take noticeable amount of CPU time. The default
Hatari "auto" frame skipping should be used unless there's a good
reason not to. It will skip converting and showing some of the frames
-if there's not enough time for them. If your monitor refresh frequency
-is lower than the selected Hatari monitor frequency (e.g. LCD monitors
-usually use 60Hz whereas Atari monochrome monitor uses 71Hz), you
-should use frameskip of one. The reason is that if your SDL library
-uses VSync to synchronize the output to screen (like OSX one?), with
-zero frame skip that forces the emulation to run slower than a real
-Atari. If SDL doesn't use VSync, Hatari does redundant work to
-convert frames you can't see.
+if there's not enough time for them.
+
+Also, if your monitor refresh frequency is lower than the selected
+Hatari monitor frequency (e.g. LCD monitors usually use 60Hz whereas
+Atari monochrome monitor uses 71Hz), you should use frameskip of one.
+The reason is that if your SDL library uses VSync to synchronize the
+output to screen (like OSX one?), with zero frame skip that forces the
+emulation to run slower than a real Atari. If SDL doesn't use VSync,
+Hatari does redundant work to convert frames you can't see.
If you are not using frame skip, disabling zooming can have
noticeable improvement on performance. You can do this by specifying
@@ -3131,36 +3849,25 @@ mode-lines (e.g. "320x200") to your xorg
to use zooming, disabling borders may help a bit.
Handling Spec512 color modes which change the ST/e palette constantly
takes some extra CPU. If you have problems with CPU usage in such
screens and you care more e.g. from the sound quality than visuals, you
-can disable the Spec512 mode handling by zeroing the threshold for that
-with the --spec512 0 option.
+can either increase the threshold or disable the Spec512 mode handling
+completely by zeroing the threshold for that with the
+--spec512 0 option.
-If your version of libSDL uses VSync to synchronize the screen
-output, drawing of the statusbar or the drive LED (when statusbar is
-disabled) may have some minor impact on performance too. Normally
-they shouldn't.
-
-Btw. Hatari currently runs best in 16 or 32 bits per pixel color depth
-mode, so try to avoid 24 bits per pixel display modes if possible.
-16-bit mode is fastest.
-
-If nothing else helps, try an earlier Hatari version. More accurate
-emulation or emulator output in newer Hatari versions means that they
-can be slower despite optimizations.
+If your version of the SDL library uses VSync to synchronize the screen
+output, drawing of the statusbar or the drive LED may have some minor
+impact on performance too. Normally they shouldn't.
There are a couple of ways to monitor and measure Hatari performance.
@@ -3185,13 +3892,13 @@ It depends on what you want to measure,
disable sound and set high frame skip like
--sound off --frameskips 60 so that
the associated external overheads are minimized. E.g. video output
-can on some platforms do VSync and measurements would then show
-your monitor refresh frequency instead of actual Hatari performance.
+can on some platforms do VSync and measurements would then show your
+monitor refresh frequency instead of the actual Hatari performance.
On Unix systems with times() function
call, only the time spent by the Hatari process itself is measured.
-On other systems much less accurate SDL "wall clock" timings are
+On other systems, much less accurate SDL "wall clock" timings are
used. To make latter more accurate you could use also
--run-vbls option to specify how many
VBLs Hatari should run before it exits. In this case it's best to
@@ -3200,7 +3907,7 @@ given as memory snapshot to Hatari with
the VBL count.
-Note that the numbers can fluctuate quite a bit, especially
+Note that these numbers can fluctuate quite a bit, especially
when the SDL timings are used, so for (statistically) reliable numbers
you may need to repeat the measurement several times. You should of
course make also sure that the system doesn't have any other activity
@@ -3208,9 +3915,9 @@ at the same time you're making the measu
This program is free software; you can redistribute it and/or modify
@@ -3232,7 +3939,7 @@ Inc., 51 Franklin Street, Fifth Floor, B
Foundation | The
GNU General Public License Emulation via software is an art and Hatari is an example of this. Emulation is to make a computer behave like a (probably) completely
@@ -3268,20 +3975,7 @@ emulation of the various custom chips an
parts of the emulated system is much trickier.
Accessing
-HDD image partitions outside of Hatari
+Accessing HDD image partitions outside of Hatari
The debugger
+
+The debugger
+xterm -T "Hatari debug window" -e hatari
+
-General debugger use
+General debugger use
Entering arguments to debugger commands
+
Calculations and immediate evaluation
+
Inspecting emulation state
+Inspecting emulation state
-> disasm
-0000aa6e: 2f08 0241 0fff 207c 00fe MOVE.L A0,-(A7)
-0000aa70: 0241 0fff 207c 00fe 78c0 AND.W #$0fff,D1
-0000aa74: 207c 00fe 78c0 2070 1000 MOVEA.L #$00fe78c0,A0
-0000aa7a: 2070 1000 4ed0 0241 0ffe MOVEA.L (A0, D1.W*1, $00) == $00fe34ae,A0
-0000aa7e: 4ed0 0241 0ffe 6712 e549 JMP.L (A0)
+> disasm pc
+$00aa6e : 2f08 move.l a0,-(sp)
+$00aa70 : 0241 0fff andi.w #$fff,d1
+$00aa74 : 207c 00fe 78c0 movea.l #$fe78c0,a0
+$00aa7a : 2070 1000 movea.l (a0,d1.w),a0
+$00aa7e : 4ed0 jmp (a0)
Selecting what information is shown on entering the debugger
+
+Debug symbols
+
+lock file debugger.ini
+
Debug symbols
+
+For a program under GEMDOS HD emulation
+
+
+symbols prg
+
+
+
+
+
+$ gst2ascii -l -o program.tos > program.sym
+
+(Options -l and -o are used to exclude useless symbols from the output.)
+
+
+For a program on a (disk) image
+
+
+symbols /path/to/the/program.tos
+
+
+
+ASCII debug symbol files
+
+
+
+
+
e01034 T random
e01076 T kbdvbase
e0107e T supexec
-> info basepage
-Process basepage information:
-- TPA start : 0x01a1bc
-- TPA end +1 : 0x7da700
-- Text segment : 0x01a2bc
-- Text size : 0xe1e0
-- Data segment : 0x02849c
-- Data size : 0x1b76
-- BSS segment : 0x02a012
-- BSS size : 0x3750
-- Process DTA : 0x01a23c
-- Parent basepage: 0x00e91c
-- Environment : 0x01a1ae
-'PATH='
-'C:\'
-- Command argslen: 0
-> symbols calc.sym 0x01a2bc
+
+symbols program.sym TEXT DATA BSS
+Breakpoints
+
+Breakpoints
-> a $e01034
-> a some_symbol
+a $e01034
+a some_symbol
-breakpoint = <condition> [ && <condition> ... ] [option]
-condition = <value>[.mode] [& <number>] <comparison> <value>[.mode]
+> help b
+'breakpoint' or 'b' - set/remove/list conditional CPU breakpoints
+Usage: b <condition> [&& <condition> ...] [:<option>] | <index> | help | all
+
+Set breakpoint with given <conditions>, remove breakpoint with
+given <index>, remove all breakpoints with 'all' or output
+breakpoint condition syntax with 'help'. Without arguments,
+lists currently active breakpoints.
+
+
+Breakpoint options
+
+
+
+
+
+a $1234 :2
+
+
+b pc > "pc" :once
+continue
+
+Breakpoint conditions
+
+
+> b help
+condition = <value>[.mode] [& <mask>] <comparison> <value>[.mode]
where:
value = [(] <register/symbol/variable name | number> [)]
- number = [#|$|%]<digits>
+ number/mask = [#|$|%]<digits>
comparison = '<' | '>' | '=' | '!'
addressing mode (width) = 'b' | 'w' | 'l'
addressing mode (space) = 'p' | 'x' | 'y'
- option = : <count> | 'once' | 'trace'
+
+
+
+db (r0).x = 1 && (r0).y = 2
-> b (a0) = "d0"
+b (a0) = "d0"
+
+
+
+b ($ff820).w & 3 = (a0) && (a1) = d0 & %1100
+b d0 > $20 && d0 < $40 && d0 ! $30
+
+
-Tracking breakpoint conditions
+
+
+b pc > "pc"
+
+
-b (r0).x = 1 && (r0).y = 2
-b pc = $64543 && ($ff820).w & 3 = (a0) && d0 = %1100
+b pc > pc
+b ($ffff9202).w ! ($ffff9202).w :trace
+
+Breakpoint condition notes
+
+
+
+
+
+
+For breakpoints that track just a single IO register memory address, or
+multiple ones of which none are modified by Hatari,
+only by emulated code, this is not a problem, they get triggered as
+expected.
+
+However, if you have a breakpoint that tracks multiple IO registers
+where some of them are updated by Hatari, for example to check that
+other Blitter registers aren't updated while control register
+indicates Blitter to be active (busy), things don't work as expected!
+Breakpoint variables
+
+b pc = TEXT :once
+
+Note1: It's better to trigger it only once because if you'd leave it on,
+during reboot you would get a warning for every instruction until TOS sets
+a valid basepage.
+
+Note2: you cannot use an address breakpoint for this because value of
+a variable given to address breakpoint is evaluated when it's set, not
+at run-time, so it cannot get the new value that the TEXT variable
+gets when you start a program.
+
+m DATA
+m BSS
+
+
+b HBL = "HBL+20"
+
+
+b AesOpcode ! AesOpcode && AesOpcode < 0xffff :trace
+
+
+info gemdos 1
+
+
+
+Chaining breakpoints and other actions
+
+
+
-> b ($ffff9202).w ! ($ffff9202).w :trace
+b GemdosOpcode = 0x3D :trace :file program.ini
+
+b pc = TEXT :trace :file trace.ini
+
+
+symbols prg
+trace gemdos,cpu_symbols
+b VBL = "VBL+4" :trace :file disable.ini
+
+
+trace none
+b all
+
+
-> b pc > pc :once
-> a some_symbol :once
+hatari --parse break.ini /path/to/your/program.tos
+
+
+
Tracing
+
+Tracing
+
+
-
Build notes
+
+Profiling
Collecting the profile data
+
+
+> profile on
+Profiling enabled.
+
+
+> c
+Returning to emulation...
+Allocated CPU profile buffer (27 MB).
+
+
+
+Allocated CPU profile address buffer (57 KB).
+ROM TOS (0xE00000-0xE80000):
+- active address range:
+ 0xe00030-0xe611a4
+- active instruction addresses:
+ 14240 (100.00% of all)
+- executed instructions:
+ 4589668 (100.00% of all)
+- used cycles:
+ 56898472 (100.00% of all)
+ = 7.09347s
+Cartridge ROM (0xFA0000-0xFC0000):
+ - no activity
+
+= 7.09347s
+
+Investigating the profile data
+
+
+> h profile
+'profile' - profile CPU code
+Usage: profile <on|off|stats|counts|cycles|misses|symbols|callers|stack|addresses|save> [count|address|file]
+ 'on' & 'off' enable and disable profiling. Data is collected
+ until debugger is entered again at which point you get profiling
+ statistics ('stats') summary.
+
+ Then you can ask for list of the PC addresses, sorted either by
+ execution 'counts', used 'cycles' or cache 'misses'. First can
+ be limited just to named addresses with 'symbols'. Optional
+ count will limit how many items will be shown.
+
+ 'addresses' lists the profiled addresses in order, with the
+ instructions (currently) residing at them. By default this
+ starts from the first executed instruction, or you can
+ specify the starting address.
+
+ 'callers' shows (raw) caller information for addresses which
+ had symbol(s) associated with them. 'stack' shows the currect
+ profile stack, this is useful only with :noinit breakpoints.
+
+ Profile information can be saved with 'save'.
+
+
+
+> profile counts 8
+addr: count:
+0xe06f10 12.11% 555724 move.l $4ba,d1
+0xe06f16 12.11% 555724 cmp.l d1,d0
+0xe06f18 12.11% 555724 bgt.s $e06f06
+0xe06f06 12.11% 555708 move.b $fffffa01.w,d1
+0xe06f0a 12.11% 555708 btst #5,d1
+0xe06f0e 12.11% 555708 beq.s $e06f1e
+0xe00ed8 1.66% 76001 subq.l #1,d0
+0xe00eda 1.66% 76001 bpl.s $e00ed8
+8 CPU addresses listed.
+
+
+
+> profile addresses 0xe06f04
+# disassembly with profile data:
+# <instructions percentage>% (<sum of instructions>, <sum of cycles>, <sum of i-cache misses>)
+$e06f04 : bra.s $e06f10 0.00% (48, 576, 0)
+$e06f06 : move.b $fffffa01.w,d1 12.11% (555708, 8902068, 0)
+$e06f0a : btst #5,d1 12.11% (555708, 6685268, 0)
+$e06f0e : beq.s $e06f1e 12.11% (555708, 4457312, 0)
+$e06f10 : move.l $4ba,d1 12.11% (555724, 11125668, 0)
+$e06f16 : cmp.l d1,d0 12.11% (555724, 4461708, 0)
+$e06f18 : bgt.s $e06f06 12.11% (555724, 4455040, 0)
+$e06f1a : moveq #1,d0 0.00% (16, 64, 0)
+Disassembled 8 (of active 14240) CPU addresses.
+
+Profile data accuracy
+
+
+
+
+
+Caller information
+
+
+> a _P_LineAttack
+CPU condition breakpoint 1 with 1 condition(s) added:
+ pc = $30f44
+$030f44 : 48e7 3820 movem.l d2-d4/a2,-(sp)
+> c
+...
+CPU breakpoint condition(s) matched 1 times.
+ pc = $30f44
+Finalizing costs for 12 non-returned functions:
+- 0x32a3c: _P_GunShot (return = 0x32b7e)
+- 0x32b18: _A_FireShotgun (return = 0x3229a)
+- 0x3223a: _P_SetPsprite (return = 0x32e86)
+- 0x32e4e: _P_MovePsprites (return = 0x38070)
+- 0x37f44: _P_PlayerThink (return = 0x36ea0)
+- 0x36e44: _P_Ticker (return = 0x260e0)
+- 0x25dcc: _G_Ticker (return = 0x1e4c6)
+- 0x1e29e: _TryRunTics (return = 0x239fa)
+- 0x238e8: _D_DoomLoop (return = 0x2556a)
+- 0x24d7a: _D_DoomMain (return = 0x44346)
+...
+
+
+
+> profile callers
+# <callee>: <caller1> = <calls> <types>[ <inclusive/totals>[ <exclusive/totals>]], <caller2> ..., <callee name>
+# types: s = subroutine call, r = return from subroutine, e = exception, x = return from exception,
+# b = branch/jump, n = PC moved to next instruction, u = unknown PC change
+# totals: calls/instructions/cycles/misses
+0xe00030: 0xffffff = 1 e, _main
+0xe000fe: 0xe00a0c = 1 b, memdone
+0xe0010a: 0xe04e34 = 1 s 1/5/72 1/5/72, _run_cartridge_applications
+0xe00144: 0xe04dbe = 1 s 4/118/1512 1/27/444, _init_acia_vecs
+0xe001ea: 0xe00ec6 = 1 b, _int_acia
+0xe0038c: 0xe04c28 = 1 s 1/191/2052 1/191/2052, _init_exc_vec
+0xe003a6: 0xe04c2e = 1 s 1/388/4656 1/388/4656, _init_user_vec
+...
+
+
+
+callee: caller: calls: calltype:
+ | | | /
+0x379: 0x155 = 144 r, 0x283 = 112 b, 0x2ef = 112 b, 0x378 = 72 s
+583236/359708265/1631189180 72/4419020/19123430, dsp_interrupt
+ | | |
+ inclusive costs exclusive costs callee name
+ (of calls from 0x378)
+
+Calltypes:
+- b: jump/branch
+- n: PC just moved to next address
+- r: subroutine return
+- s: subroutine call
+
+Caller data accuracy
+
+
+
+
+
+Saving profile data to a file
+
+
+> profile save program-profile.txt
+
+
+Profile data post-processing
+
+
+
+
+
+Providing symbols for the post-processor
+
+
+$ hatari_profile.py -a etos512k.sym emutos-profile.txt
+
+
+
+$ hatari_profile.py -r program.sym program-profile.txt
+
+
+
+$ gst2ascii -l -o program.prg > program.sym
+
+
+
+$ gst2ascii -l -o program.prg | grep -v -e useless1 -e useless2 | > program.sym
+
+
+
+Hatari profile data processor
+
+Parsing TEXT relative symbol address information from program.sym...
+[...]
+3237 lines with 1550 code symbols/addresses parsed, 0 unknown.
+
+Parsing profile information from program-profile.txt...
+[...]
+9575 lines processed with 368 functions.
+
+CPU profile information from 'program-profile.txt':
+- Hatari v1.6.2+ (May 4 2013), WinUAE CPU core
+
+
+
+Post-processor provided statistics
+
+
+$ hatari_profile.py -st -r program.sym program-profile.txt
+[...]
+CPU profile information from 'program-profile.txt':
+- Hatari v1.6.2+ (May 4 2013), WinUAE CPU core
+
+Time spent in profile = 34.49539s.
+
+Calls:
+- max = 187738, in __toupper at 0x52b88, on line 8286
+- 1585901 in total
+Executed instructions:
+- max = 1900544, in flat_remap_mips+14 at 0x47654, on line 7020
+- 64499351 in total
+Used cycles:
+- max = 15224620, in flat_remap_mips+18 at 0x47658, on line 7022
+- 553392132 in total
+Instruction cache misses:
+- max = 184308, in _BM_T_GetTicks at 0x43b90, on line 4772
+- 4941307 in total
+
+Calls:
+ 11.84% 187698 __toupper
+ 11.48% 182105 _BM_T_GetTicks
+ 11.48% 182019 _I_GetTime
+[...]
+Executed instructions:
+ 34.83% 22462729 flat_generate_mips
+ 14.08% 9080215 flat_remap_mips
+ 8.55% 5515945 render_patch_direct
+ 5.09% 3283328 _TryRunTics
+[...]
+Used cycles:
+ 23.62% 130702768 flat_generate_mips
+ 12.42% 68735832 flat_remap_mips
+ 9.77% 54041148 _TryRunTics
+ 5.80% 32111536 correct_element
+[...]
+Instruction cache misses:
+ 37.03% 1829764 _TryRunTics
+ 11.20% 553314 _BM_T_GetTicks
+ 9.44% 466319 _NetUpdate
+ 9.27% 457899 _HGetPacket
+[...]
+
+
+
+$ hatari_profile.py -st -i -r program.sym program-profile.txt
+[...]
+Executed instructions:
+ 34.83% 22462729 flat_generate_mips (0x04778a, 774576 / call)
+ 14.08% 9080215 flat_remap_mips (0x047646, 313110 / call)
+ 8.55% 5515945 render_patch_direct (0x047382, 29977 / call)
+ 5.09% 3283328 _TryRunTics (0x042356, 19660 / call)
+[...]
+Used cycles:
+ 23.62% 8.14728s 130702768 flat_generate_mips (0x04778a, 0.28094s / call)
+ 12.42% 4.28461s 68735832 flat_remap_mips (0x047646, 0.14775s / call)
+ 9.77% 3.36863s 54041148 _TryRunTics (0x042356, 0.02017s / call)
+ 5.80% 2.00165s 32111536 correct_element (0x04a658, 0.00001s / call)
+[...]
+Instruction cache misses:
+ 37.03% 1829764 _TryRunTics (0x042356, 10956 / call)
+ 11.20% 553314 _BM_T_GetTicks (0x043b90, 3 / call)
+ 9.44% 466319 _NetUpdate (0x041bcc, 5 / call)
+ 9.27% 457899 _HGetPacket (0x041754, 5 / call)
+[...]
+
+
+
+$ hatari_profile.py -st -p -r program.sym program-profile.txt
+[...]
+9575 lines processed with 368 functions.
+[...]
+Of all 1570498 switches, ignored 581 for type(s) ['r', 'u', 'x'].
+
+CPU profile information from 'badmood-level-load-CPU.txt':
+- Hatari v1.6.2+ (May 4 2013), WinUAE CPU core
+[...]
+Calls:
+ 11.84% 11.84% 187698 187698 __toupper
+ 11.48% 11.48% 182105 182105 _BM_T_GetTicks
+ 11.48% 22.95% 182019 364038 _I_GetTime
+[...]
+Executed instructions:
+ 34.83% 34.86% 34.86% 22462729 22484024 22484024 flat_generate_mips
+ 14.08% 14.10% 14.10% 9080215 9091270 9091676 flat_remap_mips
+ 8.55% 5515945 render_patch_direct
+ 5.09% 5.11% 94.96% 3283328 3294022 61247717 _TryRunTics
+[...]
+Used cycles:
+ 23.62% 23.69% 23.69% 130702768 131100604 131100604 flat_generate_mips
+ 12.42% 12.46% 12.46% 68735832 68928816 68930904 flat_remap_mips
+ 9.77% 9.80% 95.66% 54041148 54238744 529368824 _TryRunTics
+ 5.80% 5.82% 5.82% 32111536 32193664 32193664 correct_element
+[...]
+Instruction cache misses:
+ 37.03% 37.14% 98.57% 1829764 1835261 4870573 _TryRunTics
+ 11.20% 11.24% 11.24% 553314 555191 555191 _BM_T_GetTicks
+ 9.44% 9.49% 29.13% 466319 468782 1439340 _NetUpdate
+ 9.27% 9.29% 9.37% 457899 459197 463217 _HGetPacket
+[...]
+
+
+Interpreting the results
+
+
+
+
+Generating and viewing callgraphs
+
+
+$ hatari_profile.py -p -g -r program.sym program-profile.txt
+[...]
+Generating 'program-profile-0.dot' DOT callgraph file...
+
+Generating 'program-profile-1.dot' DOT callgraph file...
+
+Generating 'program-profile-2.dot' DOT callgraph file...
+[...]
+
+
+
+
+
+
+$ dot -Tsvg program-profile-1.dot > program-profile-1.svg
+
+ (problem with most PS/PDF and SVG viewers is that either they
+ don't allow zooming large callgraphs enough or they use huge
+ amounts of memory and get very slow)
+
+
+
+
+
+
+
+
+
+
+Making large callgraphs readable
+
+
+$ hatari_profile.py -p -g --ignore-to handler1,handler2 -r program.sym program-profile.txt
+
+
+
+$ hatari_profile.py -p -g -l 0.5 -e 2.0 -r program.sym program-profile.txt
+
+
+
+$ hatari_profile.py -p -g -l 1.0 -e 2.0 --no-leafs --no-intermediate --compact -r program.sym program-profile.txt
+
+
+
+$ hatari_profile.py -p -g --only func1,func2 -r program.sym program-profile.txt
+
+
+
+$ hatari_profile.py -p -k -r program.sym program-profile.txt
+[...]
+Generating callgrind file 'program-profile.cg'...
+[...]
+$ kcachegrind program-profile.cg
+
+
+
+
+
+
+Usage examples
+
+
+
+
+
+trace gemdos,io_all
+
+Please see Tracing section for more information
+on tracing, what's possible with it and what are its limitations.
+
+a $12345 :6
+
+
+history on
+b pc=($8)
+
+After bus error invokes debugger, 'history' command can then be used
+to see (executed memory addresses with their current) instructions
+leading to the error. The most interesting vector addresses are:
+$8 (Bus error), $C (Address error), $10 (Illegal instruction),
+$14 (Division by zero).
+
+b d1 = 5
+
+
+b d1 ! d1
+
+
+b d1 > 9 && d1 < 31
+
+
+b ($ff820a).b & 2 = 2
+
+
+b ($ff820a).b & 2 ! ($ff820a).b & 2
+
+
+b ($ff820a).b & 2 ! ($ff820a).b & 2 :trace
+
+
+b VBL = 100 && HBL = 40 && FrameCycles = 5
+
+
+b d0 = "d0 + 10"
+
+
+> trace gemdos
+> b GemdosOpcode = $3D
+> c
+[...continue until breakpoint...]
+1. CPU breakpoint condition(s) matched 1 times.
+ GemdosOpcode = $3D
+> n
+GEMDOS 0x3D Fopen("TEST.TXT", read-only)
+> e d0
+= %1000000 (bin), #64 (dec), $40 (hex)
+
+
+history cpu
+c
+[breakpoint is hit and debugger entered]
+history 16
+
+
+history on
+lock history 16
+c
+
+
+lock registers
+s
+[new register values]
+s
+[new register values]
+...
+
+
+m "a7-64"-a7
+
+
+lock file stack.ini
+
+Please see also Chaining breakpoints
+section for more examples on what you can do with the debugger input files.
+
+profile on
+c
+[after a while, use AltGr+Pause to get back to debugger]
+profile counts
+
+Please see Profiling section for more info.
+
+profile on
+symbols prg
+b pc = _my_function :quiet :noinit :file showstack.ini
+
+I.e. whenever 'my_function' address is called, quietly trigger a
+breakpoint without reseting profiling (callstack) information and run
+debugger command(s) from the 'showstack.ini' debugger script file,
+which contains following command:
+
+profile stack
+
+Build notes
+
+Performance
+Performance
Improving Hatari performance
+
+Improving Hatari performance
+Emulation options
+Emulation options
DSP
+DSP
Timer-D
+Timer-D
Compatible CPU
+FDC
+Compatible CPU
Emulator options
+Emulator options
Sound
+Sound
Frame skipping
+Frame skipping
Zooming
+Zooming
Spec512 color handling
+Spec512 color handling
Statusbar and drive LED
+Statusbar and drive LED
Measuring the performance
+Measuring the performance
Appendix
+Appendix
-Copying
+Copying
Introduction to Emulation
+Introduction to Emulation
+
-
-
-
-
-
-
-
- June 2010
-
-