Now type hatari to run the +emulator for the first time. If all goes +well, you should now be presented with a window showing you the +familiar +little green desktop of the Atari ST. Press F12 +to turn on the GUI to +configure Hatari to suit your needs, press F11 +to toggle windowed and fullscreen mode.
+ +Configuration options precedence
+ +Hatari settings can come from several sources, with later ones +overriding the earlier given ones: +
-
+
- Builtin Hatari default options (which are different for old UAE and WinUAE + CPU core builds, former defaults to ST, latter to Falcon) +
- Global /etc/hatari.cfg + (or /usr/local/etc/hatari.cfg) + configuration file +
- User specific ~/.hatari/hatari.cfg + configuration file +
- Command line arguments +
- Option changes done at run-time in Hatari options GUI, with debugger + "setopt" command, or through the (optionally enabled) Hatari command + FIFO or control socket +
Some of the run-time changes require emulation to be reset for them +to take effect.
+ + +Command line options and arguments
+ +Usage:
++ hatari [options] [disk image | directory | Atari program ] ++ +
As an argument one can give either a name of:
+-
+
- A floppy disk image, +
- A directory that should be emulated as a virtual GEMDOS HD, or +
- An Atari program that should be autostarted. In this case + the program's directory will be used as the C: drive from + where this program will be started. + +
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:
+ + + +General options
+-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
+--auto <program>
+Autostarts given program, if TOS finds it. +Program needs to be given with full path it will have under +emulation, for example "C:\DIR\PROGRAM.PRG"
+ +Common display options
+-m, +--mono
+Start in monochrome mode instead of +color
+--monitor +<x>
+Select monitor type (x = +mono/rgb/vga/tv)
+--tos-res <x>
+Select TOS resolution for color monitors +(x = low/med/high/ttlow/ttmed)
+-f, +--fullscreen
+Start the emulator in fullscreen +mode
+-w, --window
+Start the emulator in windowed mode
+--grab
+Grab mouse (also) in windowed mode
+--resizable <bool>
+Allow window resizing
+NOTE: this is supported only by Hatari SDL2 build
+--borders <bool>
+Show ST/STE/Falcon 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)
+--slowdown <x>
+Slow down emulation by factor of x +(used as multiplier for VBL wait time)
+--statusbar +<bool>
+Show statusbar (with floppy leds etc +etc)
+--drive-led +<bool>
+Show overlay drive led when statusbar +isn’t shown
+--max-width +<x>
+Preferred / maximum window width +for borders / zooming
+--max-height +<x>
+Preferred / maximum window height +for borders / zooming
+--bpp +<bool>
+Force internal bitdepth (x = +8/15/16/32, 0=disable)
+--disable-video +<bool>
+Run emulation without displaying video (audio only)
+ +ST/STE specific display options
+--desktop-st +<bool>
++NOTE: this has effect only for SDL1 Hatari build. In SDL2 build, +--desktop option controls also ST/STe mode.
+Whether to use desktop resolution on fullscreen +to avoid issues related to resolution switching (messing multi-screen +setups, several seconds delay needed for resolution switching by some +LCD monitors and the resulting sound break). Otherwise fullscreen will +use a resolution that is closest to the Hatari window size.
+As Hatari ST/STe display code doesn't support +zooming (except low-rez doubling), it doesn't get scaled (by Hatari or +monitor) when this is enabled, and you may get large black borders +around ST/STe screen. 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)
+--video-timing +<x>
+Wakeup State for MMU/GLUE (x=ws1/ws2/ws3/ws4/random, +default ws3). When powering on, the STF will randomly choose one of these +wake up states. The state will then affect the timings where border removals +and other video tricks should be made, which can give different results on +screen. For example, WS3 is known to be compatible with many demos, while WS1 can show +more problems.
+ +TT/Falcon specific display options
++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)
+--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 options
+--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 <= 2048)
+--vdi-height +<h>
+Use extended VDI resolution with height +<h> (200 < h <= 1280)
++TOS and popular GEM progams add extra restrictions for the VDI screen +size. In total screen can take at maximum 300kB, width needs to be +multiple of 128/planes, and height multiple of 16 pixels (or 8, +depending on system font height). That translates to following maximum +standard resolutions for the VDI mode: +
+monochrome
++FullHD (1920×1080), WUXGA (1920x1200) and QWXGA (2048x1152) +
+2 plane mode (4 colors)
++HD (1280x720), WXGA (1280x768) and XGA+ (1152x864) +
+4 plane mode (16-colors)
++qHD (960x540), DVGA (960x640) and WSVGA (1024x600) +
+ +Screen capture options
+--crop +<bool>
+Remove statusbar from the screen +captures
+--avirecord
+Start AVI recording. Note: recording will +automatically stop when emulation resolution changes.
+--avi-vcodec <x>
+Select AVI video codec (x = bmp/png). +PNG compression can be much slower than using the uncompressed BMP +format, but uncompressed video content takes huge amount of space.
+--png-level <x>
+Select PNG compression level for AVI video (x = 0-9). +Both compression efficiency and speed depend on the compressed +screen content. Highest compression level (9) can be really +slow with some content. Levels 3-6 should compress nearly as well +with clearly smaller CPU overhead.
+--avi-fps <x>
+Force AVI frame rate (x = 50/60/71/...)
+--avi-file <file>
+Use <file> to record AVI
+ +Devices options
+-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 <bool>
+Enable MIDI support (PortMidi only)
+--midi-in +<filename>
+Enable MIDI support and write MIDI data +to <file> (Linux only)
+--midi-out +<filename>
+Enable MIDI support and read MIDI data +from <file> (Linux only)
+--rs232-in +<filename>
+Enable MFP serial port support and use +<file> as the input device
+--rs232-out +<filename>
+Enable MFP serial port support and use +<file> as the output device
+--scc-b-out +<filename>
+Enable SCC channel B serial port support and use +<file> for the output (only for Mega-STE, TT and Falcon)
+ +Floppy drive options
+--drive-a +<bool>
+Enable/disable drive A (default is on)
+--drive-b +<bool>
+Enable/disable drive B (default is on)
+--drive-a-heads +<x>
+Set number of heads for drive A (1=single sided, 2=double sided)
+--drive-b-heads +<x>
+Set number of heads for drive B (1=single sided, 2=double sided)
+--disk-a +<file>
+Set disk image for floppy drive A
+--disk-b +<file>
+Set disk image for floppy drive B
+--fastfdc +<bool>
+Speed up FDC emulation (can cause +incompatibilities)
+--protect-floppy +<x>
+Write protect floppy image contents +(on/off/auto). With "auto" option write protection is according to +the disk image file attributes
+ +Hard drive options
+-d, --harddrive +<dir>
+GEMDOS HD emulation. Emulate hard disk 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. If <dir> is +an empty string, then harddrive's emulation is disabled
+--protect-hd +<x>
+Write protect hard drive <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 HD +emulation
+--gemdos-case <x>
+Specify whether new dir/filenames are forced to be +in upper or lower case with GEMDOS HD emulation. Off/upper/lower, off by default +
+--gemdos-time <x>
+Specify what file modification timestamps should be used, +emulation internal (atari) ones, or ones from the machine (host) on which +the machine is running. While Atari emulation and host clocks are in sync +at Hatari startup, they will diverge while emulation is running, especially +if you use fast forward. Default is "atari". If you modify files accessed +by the Atari side, directly from the host side while Hatari is already +running, you may want to use "host" option
+--gemdos-conv <bool>
+Whether GEMDOS file names with 8-bit (non-ASCII) characters +are converted between Atari and host character sets. On Linux, host file +name character set is assumed to be UTF-8. This option is disabled by +default, in case you have transferred files from Atari machine without +proper file name conversion (e.g. by zipping them on Atari and +unzipping on PC)
+--gemdos-drive <drive>
+Assign (separately specified) GEMDOS HD to given +drive letter (C-Z) instead of default C:, or use "skip" to specify +that Hatari should add GEMDOS HD after IDE and ACSI drives (assumes +Hatari and native HD driver parse same number of partitions from +the partition tables in HD images)
+--acsi <id>=<file>
+Emulate an ACSI hard drive with given bus ID (0-7) +using image <file>. If just a filename is given, it is assigned to +bus ID 0
+--scsi <id>=<file>
+Emulate a SCSI hard drive with given bus ID (0-7) +using image <file>. If just a filename is given, it is assigned to +bus ID 0
+--ide-master +<file>
+Emulate an IDE 0 (master) hard drive with an +image <file>
+--ide-slave +<file>
+Emulate an IDE 1 (slave) hard drive with an +image <file>
+--ide-swap <id>=<x>
+Set byte-swap option <x> (off/on/auto) for +given IDE <id> (0/1). If just option is given, it is applied to +IDE 0
+ +Memory options
++--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. Other values are considered as a size in KiB
+--ttram +<x>
+Set amount of emulated TT RAM (for Falcon and TT +mode), x = 0 to 512 MiB
+ +ROM options
+-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)
+ +Common CPU options
++--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
+ +WinUAE CPU core options
+--cpu-exact <bool>
+Use cycle exact CPU emulation (cache emulation)
+--addr24 <bool>
+Use 24-bit instead of 32-bit addressing mode (24-bit is enabled by default)
+--fpu <x>
+FPU type (x=none/68881/68882/internal)
+--fpu-softfloat <bool>
+Use full software FPU emulation (Softfloat library)
+--mmu <bool>
+Use MMU emulation
+ +Misc system options
++--machine <x>
+Select machine type (x = st, megast, ste, +megaste, 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.
+ +Sound options
+--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 approximately 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.
+ +Debug options
+-W, --wincon
+Open console window (Windows only)
+-D, +--debug
+Toggle whether CPU exceptions invoke +the debugger
+--debug-except <flags>
+Specify which exceptions invoke debugger, see +"--debug-except help" for available (comma separated) exception +flags.
+--bios-intercept <bool>
++Enable/disable XBios command parsing. Allows Atari programs to use all Hatari +functionality and change Hatari state through Hatari specific +XBios(255) calls. XBios(20) printscreen calls produce also Hatari +screenshots. XBios(11) Dbmsg call can be used to invoke the debugger. +
+--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 +<flags>
+Activate debug traces, see +"--trace help" for available tracing flags
+--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 <path>
++Hatari connects to given local socket file and reads commands from it. +Use when the control process life-time is longer than Hatari's, or +control process needs response from Hatari +
+--cmd-fifo <path>
++Hatari creates the indicated FIFO file and reads commands from it. +Commands can be echoed to FIFO file, and are same as with the control +socket. Hatari outputs help for unrecognized commands and subcommands +
+--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
+--benchmark
+Start in benchmark mode (use with --run-vbls). +This allows to measure the speed of the emulation in frames per second +by running at maximum speed (don't wait for VBL). Disable audio/video +output to have as little OS overhead as possible
+ +Type hatari --help to list all +the command line options supported by a given version of Hatari.
+ + +Using the emulated system
+ +Once you have started Hatari successfully, you can use the emulator as +an almost complete Atari ST computer system.
+ +The GUI
+ +Press F12 to enter the GUI. Navigate it +with the mouse. +The GUI is rather self explanatory.
+ +The Main Menu
+ +
++You can reach the other setup dialogs from the main menu by clicking on +the appropriate buttons. +
++You can load the current settings from a configuration file by clicking +on the button, and save +the current settings to a configuration file by clicking on +the button. +
++Click to go back and continue the emulation. +All changed options will be applied. +
++Select the "Reset machine" option if you +want the emulated machine to perform a cold reset. This is equal to +switching the power off and on again on a real Atari machine. +
++Click to terminate Hatari +and return to the host OS. +
++Click to abandon any +changes that you have made. +
+ + +The File Selector Dialog
+ +
++ The file selector dialog appears whenever you are prompted to choose a file + or folder. +
++ 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. Click the button to go up one level + in the directory tree. The button takes you + to the current working directory (i.e. the folder that was current when + Hatari has been started). Click the button to + return to your home directory. The button can + be clicked to go to the root directory of the file system. +
++ When you tick the "Show hidden files" setting, Hatari will + also show files that start with a dot in the file selection dialog. +
+ +The System Dialog
+ +
++ The system dialog can be used to define the basic hardware attributes of + the machine that should be emulated. +
++ The machine type option is used to select the type of Atari computer to + be emulated: +
+-
+
- + The ST was the very first 16/32-bit computer from Atari. + Most older games and demos require an ST. TOS 1.00, 1.02, 1.04 or 2.06 + is required for running in ST mode. +
- + The Mega-ST was an slightly improved version which also + provided the so-called blitter chip (for accelerating certain graphic + operations) and a Real Time Clock (RTC) chip. A note for experts: Hatari + emulates the Mega-ST with the so-called IMP chipset, while the normal + ST is emulated with the Ricoh chipset. This gives a slightly different + behavior between the two machine types with regards to bus errors. + +
- + The STE was introduced some years later and had some more + advanced hardware features, like the blitter chip, hardware scrolling and + DMA sample sound (but no Real Time Clock). 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 is normally safe to always work in STE mode. + Also make sure to use TOS version 1.06, 1.62 or 2.0x with this machine type. + +
- + The Mega-STE was an improved version of the STE, with + 16 MHz (instead of 8 MHz) CPU frequency and a built-in Real Time Clock chip. + +
- + The TT was the advanced workstation from Atari. It + featured a 32MHz 68030 CPU, a very high monochrome resolution, and a + lot of interfaces. However, compatibility was not as high as with the + other machines. For TT emulation you need TOS 3.0x. + +
- + The Falcon was Atari's last computer, using a 16 MHz 68030 + CPU and some more interesting new hardware feature, like the Videl graphic + chip and DSP 56001 for sound. You need TOS 4.0x for running in Falcon mode. + +
+ Note: Falcon and especially TT emulation are still considered as + experimental and incomplete, so quite a bunch of programs do not work very + well yet. + Also a lot of old games and demos do not work with these machine types + anymore since the hardware is quite a bit different. There were only very + few programs that were made for the TT exclusively, while there were some + interesting games and demos specially made for the Falcon. +
+ ++ The video timings ("wakestate") settings influence the internal + timings of the ST video chip emulation. You normally do not have to change + these unless you know what you are doing, only some very few demos require + a special setting here. +
+ ++ For Falcon mode, you can choose whether you want to disable DSP emulation, + fake it or enable full emulation. Most Falcon programs only play sound or work + correctly when you enable the DSP emulation, but it needs a lot of host CPU + power (more than 2 GHz) for full emulation. So if you have a slow host CPU, + you can try if your Falcon program also runs with DSP disabled or in + the "dummy" fake mode. + Note that you cannot change this option while the DSP based program already + runs. +
++ The check boxes in the "CPU and system parameters" section can + be used to fine-tune the machine and CPU types. +
++ The Blitter option can be set to enable Blitter emulation in plain ST mode. + The Blitter is a custom chip that accelerates some graphical operations. + Note that in Mega-ST, STE and Falcon mode, the Blitter is always enabled + (since these machines have always been sold with a Blitter chip). The TT + was always shipped without the Blitter chip. +
++ The "Patch Timer-D" option changes the Timer-D initialization from + TOS. TOS uses the MFP timer D as a baudrate generator for RS232. However, the + TOS default value slows down the emulation. The patch gives you a better + performance. It is normally safe to enable the patch, but if you encounter a + program that does not work, you can try to disable the patch to see if it + works better. +
++ With the "Boot faster" option, Hatari patches the TOS ROM and some + system variables, to speed up the boot process of the emulated system, e.g. + by simulating a warm reset. This is a convenient option, but some very few old + programs rely on an unmodified boot process, so in rare cases this option has + to be switched off to get those programs running. +
++ NOTE: The emulated Atari system is very very sensitive to all of + these options and it is strongly recommended to reset the emulation after + changing them (for most things that's done automatically). + Most settings are also selected automatically when one uses the + --machine command line option. +
+ + +The CPU Dialog
+ +
++ The CPU type option can be used to select the level of the central processing + unit. If you are not sure what to use, simply select 68000 for ST and STE + machines and 68030 for TT and Falcon emulation, since this were the original + configurations used in the Atari computers. In case you want to vary + the CPU type, you have got to be aware of some constraints: +
+-
+
- + Atari ST and STE have only been shipped with a 68000 CPU, so for best + compatibility with old programs, you should choose this CPU type. + +
- + If you are going to use TOS 1.0x, you also have to select the 68000 CPU, + since these TOS versions are not aware of the higher CPU levels yet. + If you want to use a higher CPU level with the ST or STE machine type, + you have to use TOS 2.0x instead. + +
- + Atari TT and Falcon computers were using the 68030 CPU, so you should select + the 68030 CPU type for these machines. + +
- + TOS 3.0x and 4.0x also only work with a CPU >= 68020. + +
- + 68010 and 68040, 68060 have never been used in official Atari computers, + so don't use these CPU types unless you have got some good reasons. + +
- + The 68060 option is only available in the "WinUAE" builds of + Hatari, and is currently also considered as experimental, so do not use + this option unless you know what you are doing. + +
+ The CPU clock option can be used to select the frequency that is used + to clock the CPU. 8 MHz is the standard for ST and STE and the most + compatible frequency for old software. + Use 16 MHz for Mega STE and Falcon emulation. + The CPU in the TT was clocked with 32 MHz. +
+ ++ The "Prefetch mode" option is used to enable the emulation of 68k + address errors and the so-called CPU prefetch buffer. This is needed for best + compatibility, but it slows down emulation a little bit so you can disable it + if you don't need it and if you have a slow host system. +
++ The "Cycle exact", the "MMU emulation" and + "24-bit addressing" option are only available in the + "WinUAE" builds + of Hatari. They are considered as experimental and should only be changed + if you know what you are doing. +
+
+ The FPU settings are also only available with the "WinUAE" builds
+ of Hatari. They can be used to select the type of floating point unit of CPUs
+ >= 68020. In the non-WinUAE builds of Hatari, the FPU is always enabled for
+ 68030 and 68040 CPUs.
+ When emulating the FPU, you can use your own PC's CPU/FPU to do the math.
+ This is the default and fastest method, but recent CPU might have some slight
+ differences in rounding when compared to a real Motorala FPU.
+ For higher precision, you can select the "Softfloat" emulation mode : this will
+ emulate all the FPU operations using only the CPU and with the same rules as the
+ Motorala's FPU. In that case, FPU emulation will be a little slower.
+
The Floppy Disks Dialog
+ +
++ 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. +
++ Each drive can be enabled or disabled (as if it was not connected or turned + off). You can also choose to emulate a single sided drive instead of a double + sided one (some games or demos will have a different behaviour in single sided + mode). +
++ Click on the button next to the + A: and B: option to go to the fileselector to choose a disk image for the + corresponding drive. +
+Click on to eject a disk image +from the emulated drive. The emulated ST will act as if had no floppy +disk in its drive.
+You can specify a default directory where Hatari will start to +browse the filesystem.
+
+Check the "Auto insert B" option if you want Hatari to be smart and
+insert the second disk of a two disk game automatically.
+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 fast FDC (Floppy Disk Controller) emulation. + + "Fast floppy access" option will speed up disk accesses, but this can + cause incompatibilities with programs that expect correct delays + (some games/demos don't expect data to be read too fast from the + disk). For example, when using STX images, most protections will fail + if fast floppy access is enabled. +
++ If you want, you can set Hatari to write-protect your disks. Atari ST + viruses can spread on disk images, so that can be a good idea. However, + note that some programs won't work correctly (or at all) with write + protected disks, and things like saving highscores in games will fail. +
+ +
++ If you need to create a new blank disk image, click on + . + Parameters for the new image can be set in the following dialog. HD + and ED disk sector counts are for larger, non-Atari disk sizes, they + can be useful with programs that don't work from hard drive, or with + with GEMDOS HD emulation. + Click on to save the new image or on + to return to the disk dialog. +
++ After clicking , a fileselector + appears. You can browse the filesystem now. Select the target directory, + click beside "File:" and type in a name for the new disk image. + The name should terminate with .st or .msa. +
++ Hatari can currently create plain .ST and .MSA disk images exclusively. + hmsa command line utility can be used + to convert disk images between .ST and .MSA formats. +
+ + +The Hard Disks Dialog
+ +
++ This dialog can be used to change the hard disk settings. +
++ Here you can select a hard disk image file for ACSI, SCSI or IDE hard drive + emulation, or you can select a host directory to be emulated as the Atari + hard drive. Use the arrow buttons to select the ID of the drive that you + want to set, then click on to choose + a file which should be used for providing the contents of the hard disk, + or click on to disable the current ID. +
++ IDE controllers are using a 16-bit interface, so depending on where the + contents of a real hard disk have initially been created (on an Atari + machine or on a PC), and depending on where the contents have been read + out from the disk, 16-bit values in the image might be byte-swapped. + Hatari can either try to detect this situation automatically (when + "Auto" is selected), or you can tell Hatari whether it should + always byte-swap the disk image contents or not. +
+
+ GEMDOS HD emulation can be used to provide a folder on your host
+ computer file system as hard drive(s) to the emulated Atari. Select
+ to choose a folder, or
+ to disable the drive(s) again.
+
+ The "Atari <-> host 8-bit filename conversion" setting
+ can be used to tell Hatari whether it should try to convert the character
+ set of the file names on the host to the Atari character set, since
+ modern operating systems use different character sets than Atari TOS.
+ File name conversion option is best-effort conversion between
+ the host OS and Atari character set for the non-ASCII file names
+ exposed by the GEMDOS HD emulation.
+
+ GEMDOS HD emulation can override partition(s) from HD images.
+ With "Add GEMDOS HD after ACSI/SCSI/IDE partitions" option Hatari
+ tries to assign it to a drive after the partitions on HD images,
+ instead of C: (whether that works correctly depends on whether
+ your emulated Atari hard disk interprets the HD images partition
+ tables similarly to Hatari, and whether it starts assigning them
+ from C: onwards). As a last resort, you can use "--gemdos-drive"
+ command line option to explicitly specify which drive should be
+ used for GEMDOS HD.
+
+ Finally, you can also choose whether you want to provide the files on
+ GEMDOS HD only as write-protected to the Atari environment or not,
+ or whether you want Hatari to select this status automatically depending
+ on the file attributes of the file in the host file system.
+
+ Check "Boot from HD" to set given hard disk image / directory as TOS + boot device (if ACSI or IDE is enabled, it is C:, otherwise it is the + first specified GEMDOS HD drive). With command line options, the value + of this setting depends on whether you specify floppy image or harddisk + later on the command line (later one takes precedence). +
++ Note that you need TOS version >= 2.05 to boot from IDE hard drive. + ACSI hard drive emulation does not work with TOS 4.0x in Falcon mode. + For SCSI emulation, you either need to run with TT or Falcon emulation. + Please also refer to the Hard disk support + chapter for more details about hard disk emulation. +
+ + +The Memory Dialog
+ +
+You can select the amount of RAM for the emulated machine here. Only +amounts that were valid on a real unmodified STFM can be selected.
+Note: This option is critical and you are strongly advised +to reset the emulated machine +when changing this option.
+TT RAM size allows to emulate up to 512 MiB of 32-bit RAM. This is only +useful in Falcon or TT mode and require to disable "24 bit addressing" mode +in the CPU options +
Here you will find the options to save memory snapshots as well.
+Click on to save a memory snapshot +to file. You can select a new filename here.
+Click on to restore a memory +snapshot from a file. Use the fileselector to select the snapshot to be +restored.
+NOTE: Memory snapshots are not interchangeable between +different versions of Hatari. e.g. if you compile a newer Hatari, you +cannot load your old memory snapshots back.
+ + +The ROM Dialog
+ +
+Here you can select the TOS image to use. Click on to select it via the fileselector. +You can also select an optional cartridge image to use. Click on to select one via the fileselector. Click on to disconnect the custom cartridge image. +
++Depending on the machine type that you want to emulate, you can either use +EmuTOS, or you must use a TOS version that supports the machine type. +For ST mode, use TOS 1.00, 1.02, 1.04 or 2.06. +For STE mode, use TOS 1.06, 1.62, 2.05 or 2.06. +If you want to use the TT mode, you must specify a TOS 3.05 or 3.06 image here. +And in Falcon mode, you have to use either TOS 4.00, 4.02, 4.04 or 4.92. However, +you should always use TOS 4.04 for Falcon mode, it is the most common one. +Also note that TOS 4.92 cannot be booted from a boot disk (like it is done on a +real Falcon), you have to specify it directly in the TOS ROM setup dialog here. +
++Keep in mind that any custom cartridge image will not work together with +GEMDOS HD emulation or the VDI extended resolution emulation +since some additional driver code will be used in the cartridge memory +space for these emulations. +
++Note: These options are critical and you are strongly +advised to reset the emulated ST +when changing one of these option. +
+ + +The Joystick Dialog
+ +
+In this dialog, you can configure the emulated joysticks. +With the upper two arrows, you can choose the joystick which you want to +configure.
+Joystick 1 is the normal ST joystick port and 99.9% of all ST games +use this port. +Joystick 0 emulates a joystick plugged into the ST mouse port +and is often used in games for two players.
+With STE joypad A and B, you can enable the emulation of Jaguar joypads +which are plugged in the enhanced joystick ports of the Atari STE. +Only very few STE games support these joypads, so you often won't need this.
+Finally, Hatari also emulates joysticks which were plugged on the parallel +port with a special adapter on a real ST. These were used in some few +multi-player games like "Gauntlet 2".
+For each ST joystick, choose whether you want to disable it, +use the keyboard for emulation or use a real PC joystick.
+For keyboard emulation, you can select the keys by pressing the + button. You will be prompted to press +the keys for up, down, left, right and fire.
+If you want to use a real PC joystick for the emulation, you should connect +it to your PC before you start Hatari. Then you can choose the joystick with +the two lower arrows.
+Check the "Enable autofire" option if you are too lazy to pound +on the fire button in shoot'em-up games. However, this option only works with +certain games. In some other games, it gets worse if you enable this option.
+See also the chapter "Emulated Joystick" for details.
+ + +The Atari Monitor Dialog
+ +
++ Here you control the video output of the emulated Atari. +
+
+ You can select which sort of monitor to use. This option depends on
+ the machine type which you have selected in the "System options"
+ dialog. In ST and STE mode, you can choose between monochrome mode
+ (select "Mono") and color mode (select one of the other monitor types).
+ Note that when you select "TV" and use zoomed low resolution or
+ 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!
+ 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
+ Falcon demos/games require a RGB or TV mode, and do not work with
+ VGA, although there are also few VGA-only games and demos.
+
+ "Show ST/STE borders" toggles the displaying of the borders around the ST / + STE. Some demos and games use the screen borders for displaying + additional graphics. As enabling this option increases CPU computing time, + don't enable it if you have a very slow computer. + Borders are shown also in Falcon emulation, but Videl emulation doesn't + yet support palette effects. + This option doesn't affect TT screen mode or extended VDI resolutions. +
+
+Extended VDI resolutions will emulate a sort of extended graphics card
+in the emulated machine, which gives you larger (2-16 color)
+resolutions for GEM. Select a resolution and color depth. Check to
+activate. This mode isn't affect by the other video options mentioned
+above. Uncheck to get back to a normal ST behaviour.
+
Note that there are several gotchas with extended VDI +resolutions:
+-
+
- Only GEM conformant applications work with them, 99% of all games +and demos don't. +
- Several GEM programs accessing screen directly (like NVDI) crash +with large enough screen sizes. +
- Memory reserved for (larger) extended resolutions breaks TOS v3 memory +detection, so you need to interrupt boot up memory detection. +
- TOS v4 isn't compatible with them. In Falcon emulation you need to +use EmuTOS with extended resolutions. +
+Because TT and Falcon support natively larger resolutions, +VDI mode is most useful with ST / STE emulation. +
+ + +The Hatari Screen Dialog
+ +
++Here you control how the video output of the emulated Atari appears +on your screen. +
+ ++ Check "Fullscreen" to run Hatari in fullscreen. By default Hatari + runs in windowed mode. +
+
+ The "Frame Skip" option can be used to speed up the emulator
+ if it is running too slow on your system. Disable frame-skip if you have
+ 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.
+ Note: The frameskip option also affects the frame rate of the
+ screen animation recording!
+
+Indicators that you can have on the Hatari window: +
+-
+
- "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. +
- "Drive led" is a colored rectangle shown on top of the Hatari window +contents. It will show any disk (floppy or hard drive) activity. +
- "None" turns both of above options off. +
+"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 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. Note that there are several limitations +in this and the "Keep desktop resolution" option, partly because Hatari +has different implementations for different video modes: +
+-
+
- VDI resolutions (selectable in Atari Monitor dialog) aren't scaled. +
- ST and STE video emulation supports only doubling of the ST-low + resolution. +
- Hatari doesn't support downscaling. If the original Atari resolution + is larger than the specified size (e.g. TT-high), the Hatari screen + size will also be larger than requested. Hatari Falcon/TT window size + will be limited to the Desktop size though. +
- TT and Falcon resolutions support only integer scaling ratios. + If the scaling ratio cannot match the requested size exactly, Hatari + will use a ratio that will produce smaller size closest to the + requested one. +
+You should set these values to a size that suits best your monitor +resolution. It is intended to help in getting Hatari to best use your +monitor space on a windowed mode and in fullscreen avoiding "fuzzy" +scaling done by your LCD monitor. +
++Giving "-z 2" option on command line will reset max zoomed size to +default values and "-z 1" will disable all zooming. +Note that zooming takes additional CPU computing time and should +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. +
++Selecting "Crop statusbar" option will leave statusbar out from +the screenshots and recorded videos. +
+ +The Keyboard Dialog
+ +
+Here you can select the keyboard mapping to use. Two different mappings + called "Symbolic" and "Scancode" are predefined.
+"Symbolic" tries to map the symbolic values of your PC keys + to the ST keys. It should be working pretty good on all systems as long + as your keyboard layout looks close to the standard English keyboard + layout. However, you might experience some problems with special keys like + brackets etc.
+"Scancode" uses the scancode values of your PC keys for keyboard mapping. + This only works on certain architectures like Linux where the scancodes are + similar to the ST scancodes (e.g. it does not work on macOS with SDL1.2). + If it works on your system, this often gives better results than the symbolic + mapping. Note that you also need a TOS version with the right language + (e.g. use a French TOS if you are using a French keyboard).
+You can also load a custom keyboard mapping file here if you wish. Please + note that the custom keyboard mapping will use the "symbolic" + mapping for all keys that are not defined by your map file. Have a look + at the supplied example mapfile (keymap-sample.txt) to see how to create + your own keyboard mapping.
++ The "Shortcuts" section can be used to configure the keyboard shortcuts + that can be activated while the emulation is running. Hatari supports + two sets of keyboard shortcuts: The first type is activated by pressing a + modifier key (AltGr / right Alt by default, Cmd key on macOS) together with + the key, and the second type is directly activated by pressing a single key, + without additional modifier key. + Use the arrow buttons to select the shortcut that you want to change, + then press one of the buttons to + change the key for the shortcut. You'll be prompted to press the key + that should be used. + If you reconsider and don't want to change the key, you can press the + left mouse button instead. By pressing the right mouse button during + the prompt, you can also erase the current shortcut setting. +
++ The last setting in this dialog can be used to disable the key repetition + in fast forward mode. When the emulator runs in fast forward mode, and you + want to type text, it can be annoying that the emulated system detects + multiple key events due to the key repetition of the emulated system. + So this can be avoided by enabling this option. +
+ + +The Sound Dialog
+ +
+Here you can control the sound subsystem.
+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. + For most modern computers, 44100 Hz or 48000 Hz should be fine. + For older or slower host systems, you should use a lower frequency. + 12517, 250033 and 50066 Hz are frequencies supported by + 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 + the sound is recorded in. The button + is a toggle so you will need to return to the GUI to switch sound recording off + again (or to use the keyboard shortcut for that). +
+ + +The Devices Dialog
+ +
+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 RS232 support. +The RS232 device is configured according to the settings of +the emulated MFP RS232 of the Atari ST/STE/TT. This means Hatari will +automatically use baudrate and handshaking as configured for the +emulated machine.
+Click on to select suitable +device files for serial input and output. On Linux a good choice is +/dev/ttyS0 or /dev/ttyS1. +
+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 +select the correct MIDI device file, how to set up software sound +synthesizing on Linux (using Alsa) if your sound card/driver doesn't +support MIDI, and how to set up MIDI networking e.g. between multiple +Hatari instances. +
+ + +Keyboard shortcuts for the SDL GUI
+ +There are multiple ways to interact with the SDL GUI.
+ +TAB and cursor keys change focus between UI elements. Additionally +Home key moves focus to first item, End key to last one. Initially +focus is on default UI element, but focus changes are remembered +between dialog invocations. Enter and Space invoke focused item. UI +elements with underlined characters can be invoked directly with Alt + +key with that character. Alt + arrow keys will act on arrow +buttons.
+ +Most importantly:
+-
+
- Options GUI main view: Enter accepts configuration, ESC +cancels it. +
- Options GUI dialogs: Enter (or End+Enter if focus was moved) +returns back to main view. +
- Fileselector: Page up and down keys scroll the file list. +Enter on focused file name selects it. Enter on OK button accepts +the selected file. ESC cancels the dialog/selection. +
- Alert dialogs: Enter accepts and ESC cancels the dialog. +
Keyboard shortcuts during emulation
+ +While the emulator is running, you can activate or toggle various +features via Hatari keyboard shortcuts. Most of them require the +AltGr (right Alt) +modifier key. On Mac macOS, the Cmd key ⌘ is used instead. +Below are listed the default shortcut key bindings:
+| Option | -Purpose | -||
| -h (--help) | -prints command line options and terminates | -||
| -v (--version) | -prints version information and terminates | -||
| -m (--mono) | -starts the emulated Atari ST in monochrome -resolution | -||
| -f (--fullscreen) | -tries to use a fullscreen mode | -||
| -j (--joystick) | -activates joystick emulation via cursor keys | -||
| --nosound | -disables sound (makes emulation faster) | -||
| --frameskip | -drops every second frame (accelerates -emulation) | -||
| -D (--debug) | -activates the simple builtin debugger | -||
| --slowfdc | -slows down FDC emulation (needed to make some games and demos work) | -||
| -d <dir> (--harddrive <dir>) | -emulates <dir> as a hard disk | +Shortcut | +Purpose |
|---|---|---|---|
| --hdimage <imagefile> | -emulate hard disk with an image file | +AltGr+a | +record animation |
| --tos <imagefile> | -specify TOS ROM image to use | -||
| --memsize x | -set amount of emulated RAM - x=0 for 512K, x=1,x=2 or x=4 for 1,2 or 4 MB |
+ AltGr+g | +grab a screenshot |
| --cpulevel x | -specify CPU (680x0) to use (TOS 2.06 only!!) | +AltGr+i | +boss key: leave full screen mode, pause Hatari + and iconify its window |
| --compatible | -use a more compatible but slower 68000 CPU mode | +AltGr+m | +(un-)lock the mouse into the window |
| --blitter | -enable blitter emulation | +AltGr+r | +(warm) reset the ST |
| --vdi | -use extended VDI resolution | -||
| --printer | -enable experimental printer support | +AltGr+c | +cold reset the ST (same as the original power switch) |
| --midi <filename> | -enable experimental MIDI output to the mentioned file | +AltGr+d | +open dialog to select/change disk A |
| --rs232 <filename> | -enable experimental RS232 communication via the mentioned file | +AltGr+s | +enable/disable sound |
| -c <filename> (--configfile) | -Use the mentioned file as configuration file instead of ~/.hatari.cfg | -
Using the emulated system
-Once you've started Hatari succesfully, you can use the emulator as -an allmost complete Atari ST computer system.
- -The GUI
- -General usage
-Press F12 to enter the GUI. Navigate it with the mouse. -The GUI is rather self explanatory.
-Click to go back to the emulated ST. All checked options will be applied.
-Check the option if you want the emulated ST to perform a soft reset. This should be equal to pressing the reset button on your ST. -
-Click to terminate Hatari and return to the host OS.
-Click to abandon any changes made.
- -The System Dialog
-Check the CPU type to use here, enable prefetch mode and if the Blitter should be active.
-For best Atari ST compatibility choose plain 68000 here.
-The Timer-D patch changes the Timer-D initialization from TOS. TOS uses Timer-D as a baudrate generator for RS232. -The TOS default slows the emulation down so the patch gives you a faster emulation. -
-You can disable the Timer-D patch if games or demos require the original TOS setting.
-NOTE: These parameters are very sensitive to the emulated ST and it is strongly recommended to -reset the emulated ST after changing these options.
- -The Discs Dialog
-Use the upper dialog to choose which floppy disks should be emulated in the disk drives.
-You can use most standard Atari ST disk image files. See the chapter "Floppy disk images" -for details.
-Click on the button next to the A: and B: option to go to the fileselector. -You may select and browse zipped disk images as well.
-Click on to eject a disk image from the emulated drive. The emulated ST will act as if had no floppy disk in its drive.
-You can specify a default directory where Hatari will start to browse the filesystem.
-Check the "Auto insert B" option if you want Hatari to be smart and insert the second disk -of a two disk game automatically. This option will insert the second disk in drive B and some -games may not be able to find the disks there. In that rare case you will need to insert the -second disk manually when prompted.
--NOTE: This option does not always work properly. -
- -If you need to create a new blank disk image, click on . -Parameters for the new image can be set in the following dialog. Click on create to create the image or on to get back to the -disk dialog. -
--After clicking , a fileselector appears. You can browse the filesystem now. Select the target directory, click beside File: -and type in a name for the new disk image. The name should terminate with .st or .msa. -
-Hatari can currently create plain .ST and .MSA disk images exclusively.
- -Use the lower dialog to change the harddisk settings.
-You can select a harddrive image for harddrive emulation via image file here or you may select -a directory of your local filesystem to be emulated as the ST's harddrive.
-Check "Boot from HD" if you want Hatari to execute the AUTO folder on the harddrive. -This option is checked by default if you specify a harddrive image or a directory via the command line.
- -The Memory Dialog
-You can select the amount of RAM for the emulated ST here.
-Note: This option is critical and you are strongly advised to reset the emulated ST -when changing this option.
-Here you will find the options to save memory snapshots as well.
-Click on to save a memory snapshot to file. You can select a new filename here.
-Click on to restore a memory snapshot from a file. Use the fileselector to select the snapshot to be restored.
-NOTE: Memory snapshots should be considered EXPERIMENTAL and the Hatari team strongly advises you not to rely on them yet!
- -The TOS/GEM Dialog
-Here you can select the TOS image to use. Click on to select it via the fileselector.
-In the GEM setup you can select a larger resolution for GEM conformant apps. Select resolution -and colour depth. Almost all games and demos will not work in one of these resolutions.
-Note: These options are critical and you are strongly advised to reset the emulated ST -when changing one of these option.
- -The Joystick Dialog
-Here you can select which joystick you want to emulate via the cursor keys.
-Joystick 1 is the normal ST joystick port and 99.9% of all ST games use this port, Joystick 0 -emulates a joystick plugged into the ST mouse port allowing you to play 2 player games.
-If no joystick is checked here, joystick emulation is done via a connected PC joystick.
-See the chapter "Emulated Joystick" for details.
- -The Screen Dialog
-Here you control the video output of the emulated ST.
-Check "Fullscreen" to run Hatari fullscreen, default is windowed.
-Check "Interlace" if you wish to have that old TV feeling in Hatari. Every second line will be black. -This will only work in ST-MEDIUM or ST-LOW in scaled up resolutions.
-Check "Frame Skip" to speed Hatari up if emulation is too slow. This will only draw every second ST frame -instead of the default of drawing every ST frame. Uncheck if you have a fast PC.
-Check "Use Borders" if you wish to have the borders around the ST screen.
-"Force 8Bpp" will force SDL to use an 8bit video mode. You don't need this for modern video cards.
-You can select which sort of monitor to use. Check "Color" for games and demos. If you check "Mono" here, -Hatari will emulate the good old SM124 and will not allow you to switch to color modes from the running ST. -This toggle acts like a monitor switch with a color and monochrome monitor connected.
-"ST-Low mode" will control if Hatari renders ST-LOW to a 320x200 or 640x400 PC display (with borders turned off) or 384x267 or 768x534. -Basically select this to toggle between a small or a large window.
-Click to create a screenshot in .BMP format to the current working directory or click to record a sequence of single screenshots. -
- -The Keyboard Dialog
-Here you can select the keyboard mapping to use.
-Two different mappings called "Symbolic" and "Scancode" are predefined.
-You can also load a custom keymapping file here if you wish. Please note that selecting to use a custom keyboard mapping will -use the "symbolic" mapping for all keys not defined by your map file. See the supplied example mapfile on how to build your -own keyboard mapping.
- -The Sound Dialog
-Here you can control the sound subsystem.
-Check if you want emulated sound at all. Emulation is faster if sound emulation is turned off.
-3 frequencies from low to high quality are available. Experiment a little bit to find out which fits best for your setup. -Medium quality will work ok in most cases.
-You can select to record a piece of sound here. Check which format to use and click the button. It is a toggle button so -you will need to return to the GUI to switch sound recording off again.
- -The Devices Dialog
-Check here if you want to enable experimental printer support. See the chapter "Emulated printer" 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.
-NOTE: As the printer emulation is not perfect yet, activated printer support may interfere with the emulated sound. -This is due to the fact that the Atari ST uses some general I/O ports of the soundchip for the printer port. The Hatari team suggests to -disable printing while using games and demos. -
-Check the second checkmark if you want to enable experimental 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 emulated ST.
-Select a suitable device file for input and output. Click on to select. -A good choice is /dev/ttyS0 or /dev/ttyS1. -
-You can enable MIDI as well. This currently work for outputting MIDI data only. A good choice is /dev/midi00.
-Click on to select a suitable MIDI device file for output.
-Your sound driver must support MIDI to make this work.
- -NOTE: RS232 and MIDI emulation are very experimental, too. -Don't enable them unless you really need them! -
- -Keyboard shortcuts
-While the emulator is running, you can activate or toggle various -features via the following keyboard shortcuts.
- -| Shortcut | -Purpose | +AltGr+q | +quit the emulator |
| ALTGR+a | -record animation | +AltGr+x | +toggle normal speed/fast forward |
| ALTGR+g | -grabs a screenshot | +AltGr+y | +enable/disable sound recording |
| ALTGR+i | -boss key: leave full screen mode and iconify window | +AltGr+k | +save memory snapshot |
| ALTGR+j | -activates joystick emulation via cursor keys | +AltGr+l | +load memory snapshot |
| ALTGR+m | -(un-)locks the mouse into the window | +AltGr+j | +toggle joystick emulation via cursor keys + on/off between ports 0 and 1 |
| ALTGR+r | -(warm) reset the ST | +AltGr+F1 | +switch joystick type on joy port 0 |
| ALTGR+c | -coldreset the ST (same as the original power switch) | +AltGr+F2 | +switch joystick type on joy port 1 |
| ALTGR+s | -enable/disable sound | +AltGr+F3 | +switch joystick type for joypad A |
| ALTGR+q | -quit the emulator | +AltGr+F4 | +switch joystick type for joypad B |
| ALTGR+x | -toggle normal/max speed | +AltGr+b | +toggle borders on/off |
| ALTGR+y | -enable/disable sound recording | +AltGr+f or F11 | +toggle between fullscreen and windowed mode |
| F11 | -toggles fullscreen and windowed mode | +AltGr+o or F12 | +activate the options GUI |
| F12 | -activate the GUI You may need to hold SHIFT down while in windowed mode. |
+ Pause | +pause emulation |
| PAUSE | -will go to the debugger if it was activated at compile time | +AltGr+Pause | +invoke the internal Hatari debugger |
You can change the key bindings from the Hatari configuration file. +See keymap-sample.txt file for instructions.
+ +Emulated Atari ST keyboard
+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 |
ALTGR will act as ALTERNATE as well as long as you do not press it -together with a Hatari hotkey combination.
-The right CTRL key is used as the fire button of the emulated -joystick when you turn on joystick emulation via keyboard.
-The cursor keys will act as the cursor keys on the Atari ST as long as joystick emulation -via keyboard has been turned off.
+If joystick emulation via keyboard is enabled, by default cursor keys +are used for the directions and right CTRL key +as the fire button. Otherwise they act as corresponding keys of the emulated +Atari ST.
+ +NOTE: Problems with simultaneous keypresses most likely aren't an +issue in Hatari as many modern keyboards report/support only three +simultaneous key presses (or even just two depending on which keys +are in question). Expensive gaming keyboards support more.
+Emulated mouse
+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 hotkey combination. -Press it again to go back to normal mouse behaviour which allows you to -work in other X11 windows while Hatari is up and running.
+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 +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 the Hatari window while +Hatari is up and running. Note: pausing the emulation will also +(temporarily) release the mouse grab.
+Middle button click emulates double click, which is very useful +in Fast Forward mode (where normal double clicking is nearly +impossible).
+Mouse scrollwheel will act as cursor up and down keys.
Emulated joystick
-The Atari ST joysticks are emulated ofcourse allowing you to play + +
The Atari ST joysticks are emulated of course allowing you to play your favourite games with Hatari.
The default mode is to use a connected PC joystick. You can use any -joystick that is supported by your kernel. If your joystick works with -other applications, it will likely work with Hatari as well. Make sure +joystick that is supported by your kernel / SDL library. If your joystick works +with other applications, it will likely work with Hatari as well. Make sure it is calibrated and then off you go. Move the stick to point into the desired direction. Please note that Hatari will not detect analogue movement as the Atari ST only had digital joysticks. The first -firebutton will act as the normal firebutton on the Atari ST while the second -firebutton will emulate a keypress of the SPACE key on the ST as many ST -games utilitze the SPACE bar for secondary game functions. (Xenon for example)
+firebutton will act as the normal firebutton on the Atari ST while the +second +firebutton will emulate a keypress of the SPACE +key on the ST as many ST +games utilize the SPACE bar for secondary game functions. (Xenon for +example)If you do not have a PC joystick or joypad, then you do not need to desperate. You can emulate one of the two Atari ST joysticks via the cursor keys. Just activate it in the GUI. Then the cursor keys will act as the joystick directions, the right CTRL key will act as the firebutton. You can still use the cursor keys as the ST's -cursorkeys in this mode as long as you press SHIFT along with the cursorkeys.
+cursorkeys in this mode as long as you press SHIFT +along with the cursorkeys. You can also configure these keys from the +joystick options.Emulated video
-Hatari by default only handles ST modes, ST-LOW, ST-MED and ST-HIGH.
-Overscan effects and socalled "Border Removal" are possible too.
-Due to the fact that these effects are achieved by using quirks and glitches in the original chips to do things beyond their specification emulation is a bit tricky for these and not all ST applications utilizing these techniques will work properly in Hatari. -Especially socalled "Sync Scrolling", a special technique to emulate the low byte of the video address, currently does not work properly in Hatari. -
-Beside that you can setup extended VDI modes. These only work with GEM-compliant applications and they are equal to fitting a videocard 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.
- -Emulated printer
-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.
-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 printing. Clicking "Print desktop" on the GEM desktop would result +
Hatari emulates all screen modes of the original machine.
++ST/STE shifter overscan effects are emulated, but due to the fact +that these effects are achieved by using quirks and glitches in the +original chips to do things beyond their specification, emulation is +a bit tricky for these effects. As a result, some demos using these +techniques might not be displayed correctly in Hatari, known ones are +listed in the compatibility.html file. +
+Beside that you can setup extended VDI modes. These only work with +GEM-compliant applications and they are equal to fitting a videocard +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.
+ +Emulated printer
+ +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 +printing. Clicking "Print desktop" on the GEM desktop would result in a messy data dump in the printer output.
-Printer emulation works best for plain text files or programs that 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.
Printer emulation works best for plain text files or programs that +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 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.
Emulated RS232
-Serial communications in Hatari is designed to directly use a serial port on your PC.
-Communications parameters are set automatically upon the settings of the emulated ST. This means all you do is to set -the communication parameters like baudrate from your ST communications software. Hatari will do the rest and handle -the serial input and output for you.
-Floppy disk images
+Serial communications in Hatari is designed to directly use a serial +port on your PC.
+Communications parameters are set automatically upon the settings of +the emulated machine. This means all you do is to set the communication +parameters like baudrate from the emulated communications software. +Hatari will do the rest and handle the serial input and output for you.
+Note that the “normal” RS232 port of Hatari is the one that +is connected to the MFP chip of the selected system. This port is only +wired on the ST, STE and TT machines, but not on the Falcon. To use serial +port emulation in Falcon mode, you have to use the “SCC channel B” +emulation instead.
+ +Floppy disk images
+Hatari does not use floppy disks directly but disk images due to differences between the floppy disk controllers of the ST and the PC. -Three types of disk images are currently supported: The raw "ST" type, the similar "DIM" type and -the compressed "MSA" (Magic-Shadow-Archiver) type.
+Several types of disk images are currently supported : + + +-
+
- +the raw "ST" type + +
- +the similar "DIM" type (not widely used) + +
- +the compressed "MSA" (Magic-Shadow-Archiver) type + +
- +the "STX" type that can store low level disk layout. This format is mainly +used to dump original games with their protection. Those images are created +on a real ST using pasti.prg + +
- +the "IPF", "RAW" and "CTR" types require the caps library. Similar to STX, they +record disk layout, but at a much precise level by storing MFM data. Most of +these dumps are made with the Kryoflux board + +
The raw type (file suffix should be "*.st") is simply a sector by sector image of a real floppy disk. You can easily create such an image -with the dd program which should normally be pre-installed on every -Unix-like system. Simply type something like dd if=/dev/fd0 of=myimage.st to create a disk image. Of course you need access to +with the dd program which should +normally be pre-installed on every +Unix-like system. Simply type something like dd +if=/dev/fd0 of=myimage.st to create a disk image. Of course you +need access to /dev/fd0, and depending on your system and the type of floppy disk you might have to use another device name here (for example I use -/dev/fd0u720 for 720kB disks). However, if the disk is copy-protected or +/dev/fd0u720 for 720kB disks). However, if the disk is copy-protected +or doesn't use a MSDOS compatible file system, this might fail. So be very -careful if you're not sure about the disk format.
-The other possibility is to image the disk on a real Atari ST. There +careful if you are not sure about the disk format.
+The other possibility is to image the disk on a real Atari ST. +For non-protected disk, there are programs like the Magic Shadow Archiver for this task. Hatari -supports this slightly compressed MSA disk images, too. Note that Hatari -only supports the "old" MSA format, there are some Magic Shadow Archiver +supports this slightly compressed MSA disk images, too. Note that +Hatari +only supports the "old" MSA format, there are some Magic Shadow +Archiver clones (like Jay-MSA) that create better compressed but Hatari-incompatible disk images. However, if you have got such a MSA -disk and want to use it with Hatari, you can still run the corresponding +disk and want to use it with Hatari, you can still run the +corresponding MSA program within Hatari to extract the incompatible disk image to a -normal floppy disk image.
-While *.ST and *.MSA are more or less the "standard" types of Atari +normal floppy disk image. +
+For protected disk, the most widely used method is to run pasti.prg on
+a real Atari ST and get a .STX image.
+
+For more complex protections or altered disk, one can use *.IPF or *.CTR
+which include tools to check MFM data and possible problems when dumping a disk.
+
While *.ST, *.MSA and *.STX are more or less the "standard" types of Atari disk images, you might sometimes also find STT or ADF images on the -internet. These currently do not work with Hatari.
- -Hatari can now also utilize *.DIM images just as *.ST ones without any problems. +internet. These currently do not work with Hatari.
+Hatari can now also utilize *.DIM images just as *.ST ones without +any problems. Note that DIM images are nearly the same as the raw ST images -(they only have an additional 32 bytes header), so you can easily transform +(they only have an additional 32 bytes header), so you can easily +transform the DIM images into ST images by stripping the header from the files. For example try something like: dd if=input.dim of=output.st bs=32 skip=1
- -If you've got a disk image that has been created with the old ST +
If you have got a disk image that has been created with the old ST emulator PaCifiST (for DOS) or with early versions of the program Makedisk, and the disk image does not work with Hatari, then the disk -probably suffers from the "PaCifiST bootsector bug" (Hatari will print a +probably suffers from the "PaCifiST bootsector bug" (Hatari will +display a warning message then). In this case, the bootsector of the disk contains some illegal data, so that the disk even does not work on a real ST any more. However, if it is a .ST and not a .MSA disk, you can -easily fix it by using a hex-editor to change the byte at offset $D (13) +easily fix it by using a hex-editor to change the byte at offset $D +(13) from 0 to 1 (don't forget to backup your disk image first, since you can also easily destroy your disk image when changing a wrong byte there). If the disk contains a bootsector program, you probably have to @@ -647,319 +2110,2608 @@ adjust the boot sector check sum, too (i $1FF).
Hatari supports disk images that are compressed with (Pk-)ZIP (file suffix must be ".zip") or GZip (file suffix must be ".st.gz" or -".msa.gz"), so you can archive your disk images into zip archives. +".msa.gz"), so you can archive your disk images into zip archives. You can also directly run the zip archives you may download from the net as long as the archive contains a disk image in .ST or .MSA format.
-Note: Hatari does not save disk images back to *.ZIP files so +
Note: Hatari does not save disk images back to *.ZIP files +so your highscores and savegames are lost if you load the game from such a zipped disk image.
+Hard disk support
-Hatari supports two ways of emulating a ST hard drive: The low-level -ACSI hard disk emulation and a GEMDOS based drive emulation.
-To use the ACSI hard disk emulation, you need a hard disk image file -with a pre-installed HD driver in it. So either try to image your old ST -hard disk or grab one from the internet. There is a HD image on the -Hatari web page for download. Perhaps we'll also provide a tool for -creating HD images one day.
-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. -That means that all files/folders should be written in capital letters -and their length mustn't exceed the 8+3 file name length limit. If you -don't want to rename all files to get capital letters, it is also -possible to store that folder on a FAT filesystem since those -filesystems are case-insensitive.
-GEMDOS drive emulation is an easy way to share files between the -host system and the emulated Atari, but it is known to be incomplete and -a little bit unstable, especially if you use it together with the ACSI -hard disk emulation. So if your programs complain that they could not -find/read/write files on the GEMDOS HD drive, you should try to copy -them to a floppy disk image or a real hard disk image!
-Note that changing the HD-image or the GEMDOS HD-folder will reset -the emulated Atari since it is not possible to switch the hard disk -while the emulator is running.
-May the fun without the price to be with you ;-) !
+ ++Hatari supports three ways of emulating Atari hard drives: The +low-level ACSI and IDE hard drive emulation and a GEMDOS based HD +emulation. In most cases the GEMDOS HD emulation is best as it allows +exchanging files easily between the emulated and the host environment. +
++Please note that changing the HD-image or the GEMDOS HD-folder will reset +the emulated Atari since it is not possible to switch the hard drive +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. +
++The maximum size of partitions inside the hard disk (images) depends on the +TOS version. TOS 1.00 and 1.02 support up to 256 MB, TOS 1.04 to 3.06 up to +512 MB and TOS 4.0x supports up to 1 GB partitions. +
++NOTE: you need to be careful when mounting device files. Depending on +the system setup (e.g. udev settings) partitions on memory cards etc. +can be mounted automatically. When Hatari is started and uses a device +file with partitions that are already mounted, data can be destroyed +(when several programs independently write to the same device). +Disable your desktop automount, or remember to manually unmount +devices before giving them to Hatari. +
+ + +GEMDOS based hard drive emulation
++With GEMDOS HD emulation, you can easily "mount" a folder from the +host file system to a drive of the emulated Atari. +
++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. For example following +directory setup: +
++partitions/ + + C/ + + D/ ++
+That is given to Hatari as "hatari -d partitions", will give you +GEMDOS HD emulated C: and D: drives. +
++GEMDOS HD emulation is an easy way to share files between the +host system and the emulated Atari, but there are also several +limitations: +
+-
+
- Directory entries are returned in a (case-insensitively) sorted +order, for consistency. E.g. moving files to a different directory and +back (without changing their names) like AUTOSORT does, doesn't change +that order. You need to rename the files. +
- Names which aren't valid TOS directory or file names, are converted +to a valid format. If there are multiple files which converted +names are identical in TOS-format, you see only one of those. +
- It is not possible to use a cartridge image at the same time +with GEMDOS HD emulation (Hatari has its own cartridge code +that is used for GEMDOS HD emulation). +
- Anything that installs its own GEMDOS handler, like MiNT, doesn't work +with GEMDOS HD emulation. Such things need to be run from a real +hard disk image. +
- GEMDOS HD C: drive conflicts with the ACSI and IDE hard drives. +If you want to use GEMDOS HD directory and ACSI/IDE disk images together, +either use the GEMDOS HD option for skipping ACSI & IDE partitions, or +use a multiple partition GEMDOS HD emulation setup and select the partition +subdirectories (see above) so that they don't conflict with the ACSI/IDE +partitions (drive letters). With HD Driver you have also another option, +see Using HD Driver +with GEMDOS HD partitions. +
- The GEMDOS HD emulation does not work (very well) with TOS +1.00 and 1.02. Use at least TOS 1.04 if you want the GEMDOS HD +emulation to work properly. +
- Fforce() file handle redirection works only for standard +handles used with GEMDOS file functions, such as Fwrite() to standard +output that is redirected to a file. File redirection is NOT supported +e.g. for GEMDOS Ccon* console functions. +
- Host and emulation have their own clocks, which will drift apart +after emulation is started, especially when emulation is +fast-forwarded or paused. Because of this, anything inside emulation +that relies on file timestamps (e.g. build utilities) may not work as +expected if you modify the files on the host after emulation is +already running. +
+If your programs complain that they could not find/read/write +files on the GEMDOS emulated drive, you can copy and use them +from a floppy disk image or a real hard disk image instead. +
+ + +ACSI & IDE hard drive emulation with EmuTOS
+ ++Accessing HD image files is easiest with EmuTOS. It supports both +ASCI and IDE interfaces, regardless of emulated machine type, and +understands DOS partition tables without additional drivers. +atari-hd-image.sh script coming +with Hatari can be used to create such image files and to copy +initial data to them. +
++If you have an hard drive (image) with Atari format partition table, +that should already have hard disk driver on it and work fine. +Partitioning/formatting them is the problem. Creating such images +from scratch is described in following sections. +
+ + +ACSI hard drive emulation
++To use the ACSI hard drive emulation, you need a hard disk image file +with a pre-installed HD driver in it. You can try to get an image of +your old ST hard disk or grab one from the internet (e.g. from the +Hatari website). +Please note that the size of ACSI hard drive is normally limited to 1 GB +due to some addressing constraints of the ACSI bus. Bigger disks were only +possible with certain host adapters – this behaviour is emulated by +Hatari, too, but you need a hard disk driver that supports these extensions. +
++To create a new ACSI hard disk image, you can start with an empty +image that you have created for example with the following command: +dd if=/dev/zero of=hd.img bs=512 count=xxx +(where 'xxx' is size in 512 byte blocks). Copy the complete AHDI 5.0 +package to a floppy disk image, then boot Hatari with this floppy disk +image and the fresh hard disk image like this: +--acsi hd.img ahdi.st. +Then start HDX.PRG from the floppy disk and format + partition the hard +disk image with it. +
++Formatting and partitioning works currently only with AHDI 5, but you +can install the AHDI 6 driver to the hard disk after it is formatted. +Restart the emulated system, run AHDI.PRG from the floppy disk to access +the hard disk image from the emulated Atari and then run HINSTALL.PRG. +After installing the hard disk driver to the fresh HD image with +HINSTALL.PRG, you can boot directly from the hard disk image. +
++HD Driver (v9) partitioning is also compatible with Hatari ACSI +emulation. CBHD and ICDPro AdSCSI drivers work on images which have +been partitioned elsewhere. +
+ + +IDE hard drive emulation
++As the IDE disk format (little endian) differs from the ACSI disk format +(big endian), you need separate disk images for them. Hatari doesn't +currently support partitioning IDE disks with AHDI, but you can do it with +Cecile. +
++First create an empty image file with the size of your choice with: +dd if=/dev/zero of=hd.img bs=1k count=xxx. +Then get the Cecile hard disk driver from +http://centek.free.fr/atari/softs/s_cecile.htm +and put it on a floppy disk image (e.g. to one named "cecile.st" using: +zip2st.sh cecile.zip). +
++Run Hatari with +hatari --machine falcon --tos tos404.rom +--ide-master hd.img cecile.st, switch to larger color resolution +and warm up your French language skills. Then start the Cecile hard +disk driver CECILE.PRG and run CC_TOOLS.APP to partition your hard +disk image. Click the "Partition" button, select "Hatari IDE disk" and set +suitable partition size with the arrows (below type field). Then click +"Valider". +
++If you only want to use your HD image in Falcon mode, you can install +the Cecile hard disk driver to the image from the Cecile CC_TOOLS.APP: +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 either HD Driver or +AHDI 6 driver on it instead (see ASCI +hard drive emulation section). +
++Then you can boot from your hard disk image by simply specifying it +with the --ide-master parameter. +
+ + +Moving files to/from hard disk images
+ +Moving files to and from Atari hard disk images can be done +either through GEMDOS HD partitions (host directories mounted inside +Hatari emulation) or accessing the images directly on the host +(outside the emulation). Both have their own limitations.
+ +If it is fine for the IDE/ACSI partitions to be first, you can +either use ACSI/IDE partition skip option, or a multipartition GEMDOS +HD setup as described in above sections. +
+ +If you want to boot from a GEMDOS HD partition i.e. such to be +before hard disk image partitions, and still to be able to access all +the IDE/ACSI partitions, you need to use HD Driver. Note: this is the +preferred method with EmuTOS (v0.9.x), because it doesn't run/use +driver installed to the IDE/ACSI image directly although its own +partition table/type support is very limited.
+ +Using HD Driver with GEMDOS partitions
+ +Uwe Seimet's HD +Driver works fine with both the Hatari GEMDOS HD partitions and normal +hard disk images. +
+ +First copy the HDDRIVER.PRG binary into your GEMDOS HD emulation +directory AUTO folder. Then start the HDDRUTIL.APP configuration utility, +locate HDDRIVER.PRG, open the +"Devices +and Partitions" dialog and select the "Preserve Existing Partitions" +option. Then you can just start Hatari with your hard disk image and +this GEMDOS HD directory, for example like this: +"hatari --harddrive gemdos-hd/ --ide-master +ide-hd.image".
+ +If you're using +the demo version +of HD Driver, you can write files only to the C: partition, i.e. in +above case only copy files from the hard disk image partition to the +GEMDOS HD partition (with some write slowdowns included into the demo +version). If you want to copy files to the hard disk image with +the demo version of the HD Driver, you need to set the hard disk +image as drive C:.
+ +To accomplish this, set the GEMDOS HD partitions to be from D: forward, +i.e. have a directory which contains only single letter subdirectories, +starting from "D" like in "mkdir gemdos-hd; +mkdir gemdos-hd/D". Then give Hatari (as the last parameter) +a boot floppy image containing the demo version of HDDRIVER.PRG in +its AUTO folder, like this: "hatari +--ide-master ide-hd.image --harddrive gemdos-hd/ hd-driver-floppy.st". +You can convert HD Driver ZIP package to floppy image with the +zip2st utility.
+ + +Accessing HDD image partitions outside of Hatari
+ ++If you want to access the hard disk image partitions also outside +the emulation, the disk image needs to have a DOS partition table. +The atari-hd-image script included +with Hatari can be used to create such an image. +
++Inside the Hatari emulator, EmuTOS can access partition(s) on these +kind of images directly without any driver software. Of the Atari HD +drivers mentioned above, Centek's Cecile and Uwe Seimet's HD Driver +(demo) work fine with these partitions. E.g. AHDI and CBHD don't. +Cecile works only with TT or Falcon. +
++To summarise; if EmuTOS is enough, use that. Otherwise, if you want to +use TT or Falcon emulation, use Cecile (or full HD Driver version if +you have it), otherwise use HD Driver (demo). +
++To access the content of the partitions on Linux host, there are two +possibilities: + +
Using Mtools
++For this you need to add an entry for the hard disk +image to your ~/.mtoolsrc and +specify which partition you want to access from the image. For +an image created with the above mentioned script, the line in +the configuration file should look something like this: +
++MTOOLS_NO_VFAT=1 +drive c: file="/home/user/hatari/hd.img" partition=1 ++
+Note that Mtools is instructed to use FAT compatibility mode because +EmuTOS cannot deal properly with VFAT file information. If you don't +want this setting for all your Mtools drives, you can set it also via +the environment like this ("::" refers to the drive image given with +the "-i" option): +
++MTOOLS_NO_VFAT=1 mcopy -spmv -i hd.img files/* :: ++ +
Using a loopback device
++This is recommended even by Mtools documentation, but it is less convenient +as it requires root rights. First you need to "loop" mount the image: +
+
+$ su
+# image="hd.img"; mountdir="hd"
+# start=$(parted $image unit s print | awk '/ 1 /{print $2}' | tr -d s)
+# losetup -f $image -o $((512*$start))
+# loop=$(losetup -a | tail -1 | cut -d: -f1)
+# mkdir -p $mountdir
+# mount -t msdos $loop $mountdir
+
++This uses parted to find out the first +partition offset in sectors and then tells losetup +to bind the first free loop device to a corresponding offset from +the hd.img image. +mount is then used to mount the file system +from the loop device on top of the "hd" directory. +
++After you have copied the relevant files to the "hd" directory, you need +to unmount the file system and remove the loop device binding before +using the disk image from Hatari: +
++# umount $mountdir +# losetup -d $loop ++ + +
The debugger
+ ++Hatari has a built-in debugging interface which can be used for +analyzing code that runs in the emulated system. +
+ ++On Unix (Linux / macOS) 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 Windows you need to use "-W" option to get console +window. You can add an icon to your desktop that does it. On Linux +it should do something like this (replace "xterm" with your favorite +terminal program): +
++xterm -T "Hatari debug window" -e hatari ++ +
+To run debugger commands from a file 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). +
+ ++Note that when debugger scripts are run, current directory is set to +the currently running script's directory i.e. all file operations are +relative to it. After script finishes, earlier current directory is +restored. To set current directory from a setup script, e.g. for +scripts run at breakpoints, you need to give '-f' option for the +'cd' command. +
+ + +Invoking the debugger
+ ++You can invoke the debugger manually by pressing the +AltGr + Pause key combination. +
+ ++With the "-D" command line option, you can toggle whether m68k +exceptions will also invoke the debugger. Which exceptions cause +this, can be controlled with the "--debug-except" option. +
+ ++Giving "-D" option at Hatari startup is not advised because TOS HW +checks generate some exceptions at every TOS boot. It is better to +toggle exception catching later from the debugger with the "setopt -D" +command. +
+ ++Alternatively, you can give "--debug-except" option "autostart" flag +(e.g. "--debug-except all,autostart"). This will enable catching of +(specified) exceptions after TOS boot, when Atari program given on +Hatari command line is autostarted. +
+ + +General debugger use
+ ++At the debugger prompt, type "help" to get a list of all +the available commands and their shortcuts: +
++Generic commands: + cd ( ) : change directory + evaluate ( e) : evaluate an expression + help ( h) : print help + history (hi) : show last CPU/DSP PC values & executed instructions + info ( i) : show machine/OS information + lock ( ) : specify information to show on entering the debugger + logfile ( f) : open or close log file + parse ( p) : get debugger commands from file + rename ( ) : rename given file + reset ( ) : reset emulation + setopt ( o) : set Hatari command line and debugger options + stateload ( ) : restore emulation state + statesave ( ) : save emulation state + trace ( t) : select Hatari tracing settings + variables ( v) : List builtin symbols / variables + quit ( q) : quit emulator + +CPU commands: + address ( a) : set CPU PC address breakpoints + breakpoint ( b) : set/remove/list conditional CPU breakpoints + disasm ( d) : disassemble from PC, or given address + profile ( ) : profile CPU code + cpureg ( r) : dump register values or set register to value + memdump ( m) : dump memory + memwrite ( w) : write bytes to memory + loadbin ( l) : load a file into memory + savebin ( ) : save memory to a file + symbols ( ) : load CPU symbols & their addresses + step ( s) : single-step CPU + next ( n) : step CPU through subroutine calls / to given instruction type + cont ( c) : continue emulation / CPU single-stepping + +DSP commands: + dspaddress (da) : set DSP PC address breakpoints + dspbreak (db) : set/remove/list conditional DSP breakpoints + dspdisasm (dd) : disassemble DSP code + dspmemdump (dm) : dump DSP memory + dspsymbols ( ) : load DSP symbols & their addresses + dspprofile (dp) : profile DSP code + dspreg (dr) : read/write DSP registers + dspstep (ds) : single-step DSP + dspnext (dn) : step DSP through subroutine calls / to given instruction type + dspcont (dc) : continue emulation / DSP single-stepping ++ + +
Entering arguments to debugger commands
+ ++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 is "%" (%1111). +
+ ++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. +
+ + +Calculations and immediate evaluation
+ ++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 registers, symbols and Hatari variables +in addition to numbers. For example to give a sum of A0 and D0 +register values to a command, use "a0+d0". +
+ ++Also within arithmetic expressions, parenthesis are used to indicate +indirect addressing, not to change the order of precedence. +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)". +
+ ++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 arithmetic, +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. +
+ ++Virtual V0-V7 "registers" can be used to store intermediate results +for calculations. For example, to get a sum of "_counter" symbol +address contents one could use following in suitable breakpoint: +
++# store counter sum to V0 virtual register +r v0=(_counter) +# store count of how many values are added +r v1="v1+1" ++
And then later on, calculate the average:
++# round the counter sum (add half count to sum) +r v2="v0 + v1/2" +# and calculate the rounded average (rounded sum / count) +e v2/v1 ++
(Another virtual register was used for rounding here, in case one +wants to continue summing the _counter values with the original +value.) +
+ ++With command argument completion (see build +notes), result from the last "evaluate" command can be inserted +by typing '$' and pressing TAB. +
+ + +Inspecting emulation state
+ ++In the beginning, probably the most interesting commands are "m" and "d" +for dumping and disassembling memory regions. You can use "dm" and "dd" +commands to do the same for the DSP. +
++> help memdump +'memdump' or 'm' - dump memory +Usage: m [b|w|l] [start address-[end address| count]] + dump memory at address or continue dump from previous address. + By default memory output is done as bytes, with 'w' or 'l' + option, it will be done as words/longs instead. Output amount + can be given either as a count or an address range. ++
+> help disasm +'disasm' or 'd' - disassemble from PC, or given address +Usage: d [start address-[end address]] + If no address is given, this command disassembles from the last + position or from current PC if no last position is available. ++
+> 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) ++ +
+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 reset to PC address every time 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 (e.g. "info videl") and Atari OS structures (e.g. "info gemdos"). +
+ + +Selecting what information is shown on entering the debugger
+ ++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". +
+ ++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: +
++lock file debugger.ini ++ +
+To disable showing of this extra information, use "lock default". +Without arguments "lock" command will show the available options +(like the "info" command does). +
+ + +Debug symbols
+ ++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"). +
+ + +For a program under GEMDOS HD emulation
+ ++If currently running program contains debug symbol table, +and it is started from GEMDOS HD emulated drive, its symbol names / +addresses are automatically loaded when debugger is entered, and +removed when program terminates.
+ ++Above happens only if there are no symbols loaded when the program +starts. If there are, you can load program symbol data manually with +the following command, after program has been loaded to the memory by +TOS (see setting breakpoint at program +startup): +
++symbols prg ++ +
+The options you need to add suitable symbol table to your programs, +depend on which toolchain you use to build it: +
+-
+
- Devpac: +
- "OPT D+,X+" +
- AHCC: +
- "-g" and "-l" options for linking +
- GCC: +
- "-g" for compilation, and no strip option for linking +(with older Hatari versions that didn't support a.out format, +also "-Wl,--traditional-format" option was needed for linking) +
- VBCC: +
- "-g" (can only be used at linking phase), when VBCC + configuration file uses "-bataritos" option for + the linker +
You can view the generated symbols (and convert them to debugger +ASCII format) with tool installed with Hatari:
++$ 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
+ ++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 a normal host file which location you can give to +the debugger: +
++symbols /path/to/the/program.tos ++ + +
ASCII debug symbol files
+ ++If Hatari complains that your program doesn't have debug symbol table, +or its symbols are in some unsupported format, and you cannot re-compile +it to include a.out or GST/DRI symbols, you have two options: +
+-
+
- Convert the symbols to ASCII format understood by the Hatari debugger. + Writing converters for other ASCII formats is easy, and Hatari already + contains converters for DSP LOD files, nm + output for MiNT/a.out binaries and AHCC map files. +
- Create the ASCII symbols file by hand while you're debugging a program. +
NOTE: nm output for GCC generated +a.out binaries includes labels also for loops, +not just functions. While loop labels are fine for debugging, they should +be removed before profiling. Besides causing misleading profile +results, loop labels can seriously slow down profiling +(call graph tracking is automatically enabled for profiling when debug +symbols are loaded, and operations done on each matched symbol address +cause huge overhead if that match is for something happening every few +instructions). +
+ + +ASCII symbols file format is following:
++e01034 T random +e01076 T kbdvbase +e0107e T supexec ++
+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. +
+ ++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 addresses (like is the case e.g. with EmuTOS): +
++symbols program.sym TEXT DATA BSS ++
+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). +
+ + +Breakpoints
+ ++There are two ways to specify breakpoints for Hatari. First, there are +the simple address breakpoints which trigger when the CPU (or DSP) +program counter hits a given address. Use "a" (or "da" for the DSP) +to create them, for example: +
++a $e01034 +a some_symbol ++ +
+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 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:
++> 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. ++ +
+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. +
+ + +Breakpoint options
+ ++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 ':'. +
+ +-
+
- <count> +
- Break only on every <count> hit. For example, to stop
+on every other time PC is at given address, use:
+
+a $1234 :2 +
+
+
+ - once +
-
+Delete the breakpoint when it is hit, i.e. trigger it only once. It may
+be useful if you just want to get a specific address. Or if you're on
+an instruction that jumps back to a start of the loop and you want to
+finish the loop, you could use:
+
+b pc > "pc" :once +continue +
+
+
+ - trace +
- +Continue emulation without stopping after printing the value that +triggered the breakpoint and doing other possible option actions. +This is most useful when investigating memory or register value +changes (explained below). + + +
- lock +
- +Show the same information on breakpoint hit as you see when entering +the debugger (see the "lock" command in +Inspecting emulation state +above). This enables also trace option as you would anyway see this +information if debugger would be entered. + + +
- file <file> +
- +Execute debugger commands from given <file> when this breakpoint +is hit. With this you have complete control over what information is +show when the debugger is hit, you can even chain breakpoints (as +explained in +Chaining breakpoints later on) +etc. Use this if "lock" option isn't enough or you want different +information show on breakpoints and when entering the debugger. + + +
- noinit +
- +Hitting breakpoint doesn't re-initialize debugger which would e.g. +cause profiling data to be reset. This implies trace option as +entering debugger would also re-initialize debugger state. This option +is mainly intended for breakpoints that use :file option to show +backtraces with "profile stack" command during +profiling. See +Usage examples section for an example. + +
+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. +
+ + +Breakpoint conditions
+ ++"b help" explains very briefly the breakpoint condition syntax: +
++> b help +condition = <value>[.mode] [& <mask>] <comparison> <value>[.mode] + +where: + value = [(] <register/symbol/variable name | number> [)] + number/mask = [#|$|%]<digits> + comparison = '<' | '>' | '=' | '!' + addressing mode (width) = 'b' | 'w' | 'l' + addressing mode (space) = 'p' | 'x' | 'y' ++ +
+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; +
+db (r0).x = 1 && (r0).y = 2 ++ +
+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 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: +
++b (a0) = "d0" ++ +
+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 corresponding value, like this: +
+b ($ff820).w & 3 = (a0) && (a1) = d0 & %1100 ++ +
+Comparison operators should be familiar and obvious, except for '!' +which indicates inequality ("is not") comparison. For example: +
++b d0 > $20 && d0 < $40 && d0 ! $30 ++ + +
Tracking breakpoint conditions
+ ++As a convenience, if the both sides of the comparison are exactly the +same (i.e. condition is redundant as it is 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: +
++b pc > "pc" ++
As:
++b pc > pc ++ +
+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: +
++b ($ffff9202).w ! ($ffff9202).w :trace ++
+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 I/O register. +
+ + +Breakpoint condition notes
+ +-
+
- +Any '!' condition should be given as the first condition. Because +breakpoint evaluation is stopped ("short-circuited") when any of the +conditions fails, the tracked value would not be updated correctly +unless tracking condition is given as the first one. + + +
-
+Hatari will internally update some register values without immediately
+updating the corresponding I/O address range memory addresses. For
+example the Busy bit for the internal Blitter control register is
+(internally) cleared when Blitter activity stops, but the actual I/O
+address for that control register gets updated only when something
+actually writes or reads that I/O address. Many HW registers behave
+like this (status registers in FDC, ACIA, MFP, Blitter...).
+
+For breakpoints that track just a single I/O 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 I/O 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
+ ++In addition to loaded symbols, the debugger supports also setting +conditional breakpoints on values of some "virtual" variables listed +by "variables" (v) command. For example: +
+-
+
- Aes/Bios/Gemdos/LineA/LineF/Vdi/XbiosOpcode variables can be used
+ to catch AES, BIOS, GEMDOS, Line-A, Line-F, VDI and XBIOS OS-calls.
+ By default they contain the 0xffff value, so to trace e.g. all AES
+ calls (instead of a specific one) one needs to use something like this:
+
+b AesOpcode ! AesOpcode && AesOpcode < 0xffff :trace +
+
+ - To stop when TOS starts next program, set a breakpoint for
+ Pexec(0,...) OS call:
+
+b GemdosOpcode = 0x4B && OsCallParam = 0x0 +
+
+ - Then, to stop emulation on the first instruction of that
+ program, set a breakpoint when program counter matches
+ the TEXT (i.e. code) segment address (taken from program
+ basepage):
+
+b pc = TEXT :once +
+Note1: It is better to trigger it only once, because if you would leave it +on, during (re)boot you would get a warning for every instruction +(until TOS sets a valid basepage). +
+Note2: you cannot use an address breakpoint for this because +variable values are evaluated at run-time only for conditional +breakpoints. +
+ - To view current program DATA and BSS segment contents,
+ use the corresponding variables:
+
+m DATA +m BSS +
+
+ - 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 "FrameCycles" variable values. If you want,
+ for example, to break after 20 HBLs, use:
+
+b HBL = "HBL+20" +
+
+
+Hint: "info" command "aes", "bios", "gemdos", "vdi" and "xbios" +subcommands can be used to list the corresponding OS-call opcodes. +For example, to see the GEMDOS opcodes, use:
++info gemdos 1 ++ + +
Chaining breakpoints and other actions
+ ++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:
+-
+
- "pexec.ini":
+
+# continue to "program.ini" on Pexec(0, ....) +b GemdosOpcode = 0x4B && OsCallParam = 0x0 :trace :once :file program.ini +
+
+ - "program.ini":
+
+# continue to "trace.ini" when program execution starts +b pc = TEXT :trace :once :file trace.ini +
+
+ - "trace.ini":
+
+# load symbols, trace gemdos & program function calls +symbols prg +trace gemdos,cpu_symbols +# continue to "disable.ini" after 4 VBLs +b VBL = "VBL+4" :trace :once :file disable.ini +
+
+ - "disable.ini":
+
+# stop tracing and remove breakpoints +trace none +b all +
+
+
+And then start Hatari with the first debugger input file: +
++hatari --parse pexec.ini /path/to/your/program.tos ++ +
-
+
- "pexec.ini" sets a breakpoint to parse debugger commands from + "program.ini" when TOS starts loading the given program + (it is first Pexec(0) after boot) +
- "program.ini" sets a breakpoint to parse debugger commands from + "trace.ini" when program code begins executing. These two steps + are needed because TEXT variable isn't valid until TOS has booted +
- "trace.ini" input file loads symbols for the run program, sets Hatari + to trace several things (see Tracing section + below) in the emulated system for few VBLs until breakpoint runs + commands from the "disable.ini" file +
- "disable.ini" input file will disable tracing and remove + all (remaining) breakpoints +
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). +
- In simpler breakpoint chain (like above), where new breakpoint +just replaces the previous one, ":once" option tells debugger that +breakpoint isn't needed after it is hit. + +
+Hint: It is better to test each input file separately before testing +the whole chain. Besides the ":file" breakpoint option, you can test +these debugger input files also with the debugger "file" command, +"file" option for the "lock" command, and with the Hatari "--parse" +command line option. +
+ +Stepping through code
+ ++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 + exception calls and DBCC branching backwards +(i.e. loops). "ds" and "dn" commands do the same for DSP (except that +"dn" doesn't skip loops). +
+ ++You can also continue with the "n" until instruction of certain +type is encountered, by giving it the instruction type: +
-
+
- "branch" matches branch instructions:
+ CPU: BCC, BRA, DBCC, JMP
+ DSP: DO/ENDO JCC, JCLR, JMP, JSET, REP
+ - "subcall" matches subroutine calls:
+ CPU: BSR, JSR
+ DSP: JSCC, JSCLR, JSSET, JSR
+ - "subreturn" matches return from subroutine:
+ CPU: RTD, RTR, RTS
+ DSP: RTS
+ - "exception" matches exceptions:
+ CPU: BKPT, ILLG, STOP, TRAP, TRAPV
+ - "exreturn" matches return from exception:
+ CPU: RTE
+ DSP: RTI
+ - "return" matches both subroutine and exception returns +
+For example: "n branch", or "dn branch". +
+ ++(Note: CHK, CHK2, FBCC, FDBCC, & FTRAPCC exception / branch CPU +instructions aren't supported currently.) +
+ + +Tracing
+ ++If you want e.g. 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 (over 40) supported +traceable things, from HW events to OS functions. +
++Notes: +
+-
+
- +If GEMDOS HD emulation isn't enabled, GEMDOS call tracing needs to be +enabled at Hatari command line, it is not possible to enable it after +TOS has initialized GEMDOS. + +
- +AES, BIOS, GEMDOS and XBIOS traces show arguments for (most of) the +calls, VDI trace shows only function calls (parsing the arguments +would be too complicated). + +
- +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 trace options 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 there isn't a trace option for something you would like to track, +you may be able to use tracing breakpoints, explained above. +For example, following tracks Line-A calls: +
++b LineAOpcode ! LineAOpcode && LineAOpcode < 0xffff :trace ++ + +
Profiling
+ ++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. +
+ +Collecting the profile data
+ ++Profiling is used by first enabling the profiler (use "dp" for DSP): +
++> profile on +Profiling enabled. ++
+And profiling will start once you continue the emulation: +
++> c +Returning to emulation... +Allocated CPU profile buffer (27 MB). ++ +
+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: +
++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 ++
+(DSP RAM will be shown only as single area in profile information.) +
+ + +Investigating the profile data
+ ++When you are back in debugger, you can inspect the collected profile data: +
+
+> h profile
+'profile' - profile CPU code
+Usage: profile <subcommand> [parameter]
+
+ Subcommands:
+ - on
+ - off
+ - counts [count]
+ - cycles [count]
+ - i-misses [count]
+ - d-hits [count]
+ - symbols [count]
+ - addresses [address]
+ - callers
+ - caches
+ - stack
+ - stats
+ - save <file>
+ - loops <file> [CPU limit] [DSP limit]
+
+ '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', i-cache misses or d-cache hits.
+ First can be limited just to named addresses with 'symbols'.
+ Optional count will limit how many items will be shown.
+
+ 'caches' shows histogram of CPU cache usage.
+
+ '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 current
+ profile stack (this is useful only with :noinit breakpoints).
+
+ Profile address and callers information can be saved with
+ 'save' command.
+
+ Detailed (spin) looping information can be collected by
+ specifying to which file it should be saved, with optional
+ limit(s) on how many bytes first and last instruction
+ address of the loop can differ (0 = no limit).
+
+
+For example, to see which memory addresses were executed most +and what instructions those have at the end of profiling, use:
++> 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. ++ +
+Then, to see what the executed code and its costs look like +around top addresses: +
+> profile addresses 0xe06f04 +# disassembly with profile data: +# <instructions percentage>% (<sum of instructions>, <sum of cycles>, <sum of i-cache misses>, <sum of d-cache hits>) + +$e06f04 : bra.s $e06f10 0.00% (48, 576, 0, 0) +$e06f06 : move.b $fffffa01.w,d1 12.11% (555708, 8902068, 0, 0) +$e06f0a : btst #5,d1 12.11% (555708, 6685268, 0, 0) +$e06f0e : beq.s $e06f1e 12.11% (555708, 4457312, 0, 0) +$e06f10 : move.l $4ba,d1 12.11% (555724, 11125668, 0, 0) +$e06f16 : cmp.l d1,d0 12.11% (555724, 4461708, 0, 0) +$e06f18 : bgt.s $e06f06 12.11% (555724, 4455040, 0, 0) +$e06f1a : moveq #1,d0 0.00% (16, 64, 0, 0) +Disassembled 8 (of active 14240) CPU 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
+ +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:
+-
+
- Executed CPU and DSP instruction counts are accurate. +
- 68000 cycle counts have been tested to be accurate to within 1%. +
- DSP cycle counts (and the variance information) should be accurate. +
- 030 CPU instruction cache hit/miss counts (provided by WinUAE CPU core) + are assumed to be accurate. +
- As to 680x0 cycles... Cycles used by a given CPU instruction depend + on what instruction(s) is executed, where it was executed (ST or + TT-RAM) and what data was processed before it (was it cached). + E.g. 030 cycle counts can be off by tens of percents. +
- FPU instruction cycles can be off by 2x. +
Caller information
+ ++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:
++> 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 stack" command can be used in breakpoints with :noinit +option to show backtraces during caller profiling.)
+ +Note: rest of this subsection is about caller information format +which is mainly of interest for people writing profiling +post-processing tools. Come back here if you think there's +some problem with callgraphs produced by those tools.
+ +Other information collected during profiling is shown with +following command:
++> 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 +... ++ +
+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 are profiling, profile caller +information will tell you: +
++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 ++
+(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). +
+ + +Caller data accuracy
+ +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 handled:
+-
+
- If there are exception(s) during a subroutine call, costs for + the exception handling will also be accounted for that subroutine. + This shouldn't be a problem unless those costs are very large, + i.e. check how much CPU your exception handlers take. +
- Indicated exception handler call type can be incorrect. +
- Profiled code doing return address related stack manipulations + confuses call tracking and produces incorrect results (profiler + has special code to handle EmuTOS AES switcher because of this). + Typically this produces large list of functions that are finalized + at profile end, so it should be easy to detect. +
- Complicated recursive calls seem to sometimes cause inclusive + costs (ones including costs of further subroutine calls) to be + incorrect. Sometimes this can be noticed by them being even + >100%. +
- On DSP, profiler heuristics assume (for speed reasons) that + conditional subroutine calls never call the very next + instruction (as that would be very bad/inefficient code). +
Saving profile data to a file
+ +It is useful to save the profile data to a file:
++> profile save program-profile.txt ++ +
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 have 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.
+ + +Profile data post-processing
+ +Saved profile data can be post-processed with (Python) script +installed by Hatari, to:
+-
+
- Get lists of functions/symbols with highest costs. +
- Get callgraphs of what functions/symbols cause those + costs and what kind of call hierarchy the profiled code + has. +
- Export profile data in Valgrind's + Callgrind format + for viewing it in + Kcachegrind + GUI. +
Providing symbols for the post-processor
+ +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 assigned 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):
++$ hatari_profile.py -a etos512k.sym emutos-profile.txt ++ +
Normal programs are relocated and you should instead give +the symbols as TEXT (code) section relative ones (-r):
++$ hatari_profile.py -r program.sym program-profile.txt ++ +
If symbols are included to your binary, first they need to be +extracted to the ASCII format +understood by the post-processor:
++$ gst2ascii -a -l -o program.prg > program.sym ++ +
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: +
++$ gst2ascii -a -l -o program.prg | grep -v -e useless1 -e useless2 > program.sym ++ + +
Post-processor provided statistics
+ +Above post-processor examples just parse + verify the given data +and produce output like this:
++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 ++ +
To get statistics (-s) and list of top (-t) CPU users in profile, +add "-st" option:
++$ 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 +[...] ++ +
If you want to see also symbol addresses and what is per call +cost, add -i option:
++$ 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) +[...] ++ +
(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):
++$ 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 +[...] ++ +
Now there's a message telling that some of the calls were ignored +because according to their "call type", they were actually returns from +exceptions, not real calls (this is mainly important for callgraph +generation, discussed below).
+ + +Interpreting the results
+ +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 precede 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:
+-
+
- Subroutine terminates before next symbol address: exclusive + cost is smaller than in-between cost because of missing + symbol information + (these are indicated with '*' in statistics). +
- Subroutine is called more through jumps/branches than through + subroutine calls: inclusive call count may be smaller than + in-between call count which includes branches/jumps. +
- Subroutine jumps/branches to another function instead of + using subroutine call, or function contains additional + (non-function) labels: exclusive cost is larger than + in-between cost. +
- Exception happening during subroutine call: exclusive cost is + (slightly) larger than in-between cost. +
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. Exit points can be seen from RTS +instructions.
+ +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 branched to. Because of +this, it is 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.
+ + +Generating and viewing callgraphs
+ +Callgraphs require that saved profile data contains caller +function address information, i.e. symbols for the code should +be loaded before starting profiling it (see +loading symbol data).
+ +Separate callgraphs will be created for each of the costs +(0=calls, 1=instructions, 2=cycles) with the -g option:
++$ 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... +[...] ++ +
Callgraphs are saved in GraphViz +"dot" format. Dot files can be viewed:
+-
+
- With "dotty" program included with GraphViz +
- With XDot + Python GUI (best option on Linux), or some platform specific viewer +
- By converting dot file to PostScript or SVG format before
+ viewing it with viewers for those:
+
+$ 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) +
+
Produced callgraph will look like this:
+
+
+Interpreting the callgraph:
+-
+
- Diamond shaped nodes are symbols called as subroutines. + Values listed in them are subroutine call costs; inclusive + (total) cost with exclusive (own) cost in parenthesis, + followed by inclusive cost count. Exclusive cost is + shown only if it differs from inclusive one. +
- Ellipse shaped nodes are for other symbols (functions + called using jumps/branches, loop labels etc). Values + listed in them are between-symbols costs, i.e. normally + they are included to inclusive (total) costs shown in + subroutine call node somewhere higher in call hierarchy. +
- Nodes which exclusive (own) or between-symbols costs + exceed default or explicitly given threshold value, + have gray background. +
- Both nodes, which inclusive or between-symbols cost exceeds + the threshold value, and the arrows to & from them, + are marked red. +
- Arrow types indicate call types; normal arrows subroutine + calls, circles branches/jumps, backarrows returns. + Exception calls and returns are indicated with dashed lines, + unknown calls with dotted lines. +
- Arrow text tells from which address (within the caller) + the call originated. If symbol had multiple callers, text + includes count of calls from that particular address, and its + percentage is of all calls done to that symbol. +
Making large callgraphs readable
+ ++If profile is for larger and more varied amount of code (e.g. program startup), +the resulting callgraph can be so huge that it not really readable anymore. +
+ +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:
++$ hatari_profile.py -p -g --ignore-to handler1,handler2 -r program.sym program-profile.txt ++ +
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, those options act only on nodes which costs are below +given threshold. Leaf nodes are ones which don't have any parents +and/or children. Intermediate ones 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:
++$ hatari_profile.py -p -g -l 0.5 -e 2.0 -r program.sym program-profile.txt ++ +
If you are 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:
++$ hatari_profile.py -p -g -l 1.0 -e 2.0 --no-leafs --no-intermediate --compact -r program.sym program-profile.txt ++ +
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 hierarchy. Instead you may +consider removing all nodes except for subroutine call ones, with the +--only-subroutines option.
+ +If you have trouble locating nodes you are 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:
++$ hatari_profile.py -p -g --only func1,func2 -r program.sym program-profile.txt ++ +
Last option for reading the callgraph is using -k option to +export the data for use in (Linux) Kcachegrind UI. Kcachegrind 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:
++$ hatari_profile.py -p -k -r program.sym program-profile.txt +[...] +Generating callgrind file 'program-profile.cg'... +[...] +$ kcachegrind program-profile.cg ++
+Usage examples
+ ++Here's a list of some common debugging tasks and how to do them +with the Hatari debugger: +
+ +-
+
- Stopping on program startup and examining its data +
- Please see Breakpoint variables +and Inspecting emulation state +sections. + + +
- Tracing specific things in the system +
- To trace e.g. all GEMDOS calls and I/O operations, use:
+
+trace gemdos,io_all +
+Please see Tracing section for more information +on tracing, what's possible with it and what are its limitations. +
+
+ - Stopping when certain PC address is passed Nth time +
- To stop e.g. after function/subroutine at $12345 is called for
+the 6th time:
+
+a $12345 :6 +
+
+
+ - Stopping when specific exception happens +
- If one wants a specific breakpoint to trigger on a specific
+exception, one can check when its handler address is called by the
+CPU. At the start of memory is the CPU exception table for exception
+vectors. So, to stop e.g. at bus error with some extra information,
+one can use following:
+
+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).
+NOTE: Normally, to invoke debugger for larger set of exceptions, one +would use Hatari's "--debug-except" option to specify on which +exceptions debugger is invoked, and "setopt -D" to enable that on +run-time. +
+
+ - Stopping when register has a specific value +
- To stop when e.g. D1 register contains value 5, set a breakpoint on:
+
+b d1 = 5 +
+
+
+ - Stopping when a register value changes +
- To stop when e.g. D1 register value changes, set a breakpoint on:
+
+b d1 ! d1 +
+
+
+ - Stopping when part of register value changes +
- To stop when e.g. D1 register lowest byte changes, set a
+breakpoint on masked lowest 8 bits:
+
+b d1 & 0xff ! d1 & 0xff +
+
+
+ - Stopping when register value is within some range +
- To stop when e.g. D1 register value is within range of 10-30,
+set a breakpoint on:
+
+b d1 > 9 && d1 < 31 +
+
+
+ - Stopping when memory location has a specific value +
- To stop when e.g. bit 1 of the Video Shifter Sync Mode byte at
+I/O address $ff820a is set i.e. video frequency is 60Hz, set
+a breakpoint on:
+
+b ($ff820a).b & 2 = 2 +
+
+
+ - Stopping when a memory value changes +
- To stop when above bit changes, set a breakpoint on its value
+being different from the current value ('!' compares for inequality):
+
+b ($ff820a).b & 2 ! ($ff820a).b & 2 +
+
+
+ - Tracing all changes in specific memory location +
- To see the new values and continue without stopping, add
+the ":trace" breakpoint option:
+
+b ($ff820a).b & 2 ! ($ff820a).b & 2 :trace +
+
+
+ - Viewing OS structure and IO register values +
- To see e.g. basepage for currently running program:
+
+info basepage +
+To see e.g. all Falcon Videl register values, use: ++info videl +
+
+
+ - Stopping at specific screen position +
- To stop e.g. when VBL is 100, HBL is 40 and line cycles is 5,
+use the corresponding debugger variables:
+
+b VBL = 100 && HBL = 40 && FrameCycles = 5 +
+
+
+ - Stopping after value increases/decreases by certain amount +
- To stop e.g. after D0 value has increased by 10, set breakpoint on:
+
+b d0 = "d0 + 10" +
+
+
+ - Examining specific system call return value +
- To check e.g. what's the Fopen() GEMDOS call return value,
+check with "info gemdos 1" its opcode, set a breakpoint for that
+and step to next (n) instruction from the trap call when breakpoint
+is hit. GEMDOS call return value is then in register D0:
+
+> 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) ++
+
+ - Seeing code leading to a breakpoint +
- To see CPU instructions executed before debugger was entered,
+you need to enable history tracking before it. Whenever
+debugger is entered, you can then request given number (here 16) of
+past instructions to be shown:
+
+history cpu +c +[breakpoint is hit and debugger entered] +history 16 +
+
+
+ - Getting instruction execution history for every breakpoint +
-
+To see last 16 instructions for both CPU and DSP whenever
+(a normal or tracing) breakpoint is hit:
+
+history on +lock history 16 +c +
+
+
+ - Single stepping so that new register values are shown after each step +
-
+
+lock registers +s +[new register values] +s +[new register values] +... +
+
+
+ - Showing current stack contents +
- To see first 64 bytes on top of the stack, use:
+
+m "a7-64"-a7 +
+
+
+ - Seeing specific information each time debugger is entered +
- To see above information whenever some breakpoint is hit,
+you enter debugger manually etc, write that command to e.g.
+stack.ini file and then use:
+
+lock file stack.ini +
+Please see also Chaining breakpoints +section for more examples on what you can do with the debugger input files. +
+
+ - Adding cycle information to disassembly +
- Profiling collects cycle usage information for all executed instructions:
+
+profile on +c +[after a while, use AltGr+Pause to get back to debugger] +d +[or if you want to see just the executed instructions] +profile addresses +
+Please see Profiling section for more info. +
+
+ - Finding where a program or the OS is stuck +
- Profiling tells from which addresses CPU is executing the instructions:
+
+profile on +c +[after a while, use AltGr+Pause to get back to debugger] +profile counts +
+Please see Profiling section for more info. +
+
+ - Seeing program callstack when breakpoint is hit +
- Profiler caller data includes +callstack information (with some limitations). + + +
- Seeing call backtraces whenever given function is called +
- Enable profiling, load symbols for the program and set breakpoint
+for the function you are interested about, in the following way:
+
+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 resetting profiling (callstack) information and run +debugger command(s) from the 'showstack.ini' debugger script file, +which contains following command: ++profile stack +
+
+
+ - Seeing how program functions/symbols call each other +
- Profile data +post-processing can provide execution callgraphs. + + +
+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. +
+ + +Build notes
+ ++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 are 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. +
+ + +Performance
+ +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 can be sped up considerably by giving up some emulation or +emulator accuracy. With ST/STe emulation, these options should be +needed only on slow devices, typically ARM and/or mobile ones (e.g. +Rasberry Pi). +
+ + +Operating system components performance
+ ++Finding out whether there's a performance problem with the system +components (like SDL) in your setup, requires profiling Hatari and +rest of the system. How to do that is OS specific. On Linux that would +involve running "perf record -a" command (as root) on the background +for few minutes while Hatari is running, and then investigating +the results with "perf report" command. +
+ ++Some other process eating CPU cycles from Hatari one can see just with +the (Linux/Unix) "top" command. +
+ + +Build options impact on performance
+ ++Linux: Some HW platforms don't have properly HW accelerated +3D driver and SDL implementation. On these platforms it's better to +build Hatari with SDL v1.x than SDL 2.x, as latter can cause CPU +based 3D driver to be used for scaling Hatari graphics. +
+ ++MacOS: With SDL v1.x, 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 macOS +backend and how macOS itself composites non-fullscreen window +contents. These shouldn't be an issue with the SDL2 build of Hatari. +
+ ++Compiler: Unless you have disabled compiler optimizations +(like GCC's -O2 or -O3 options) in the Hatari build, the extra +optimization flags (like GCC's "-mtune=i686") don't seem to have very +large effect on Hatari performance. Using GCC -O3 option instead of +-O2 can give minor (5-10%) performance improvements for things (mainly +demos) that use very heavily interrupts. +
+ ++CPU emulation: Hatari can be built with two different CPU +core implementations. The newer WinUAE CPU core has more accurate CPU +emulation and supports all of the higher end 680x0 CPU features. This +accuracy causes it to be clearly slower, than the OldAUE CPU core +implementation. If run-time options (acceptable to you) don't give +enough performance, give the OldUAE CPU core also a try. +
+ ++Older versions: If nothing else helps, try (building) much +earlier Hatari version. More accurate emulation in newer Hatari +versions means that they can be slower despite optimizations. +
+ +Run-time options not affecting emulation accuracy
+ ++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 faster with SDL1. MacOS uses always 32-bit mode. +
+ + +Run-time emulation options
+ ++Emulation options have the largest impact on Hatari performance. These +options can be changed from the Hatari GUI System and CPU dialogs and +the emulation needs to be rebooted for any of these changes to take an +effect! They are enabled by default. +
+ +DSP (Falcon)
+ ++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 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. +
+ +CPU: cycle exact (030/TT/Falcon)
+ ++WinUAE CPU core supports 030 cache emulation for cycle accuracy. This +is very heavy. Unless program needs cycle accuracy to work correctly, +you can disable it. Many Falcon demos need it, application and games +normally don't. +
+ +Timer-D
++With ST/STe, the single largest factor contributing to general Hatari +emulation performance is the handling of interrupts. Enabling Timer-D +patching option (about) doubles Hatari ST/STE emulation performance +with OldUAE CPU core as it significantly reduces the number of +interrupts generated by the emulated Atari machine. Using this has +adverse effect only for very rare programs. +
+ +FDC
++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. +
+ +CPU: prefetch
++After the DSP, cycle accuracy and interrupts, m68k emulation takes +most time. Disabling the "Prefetch" / "Compatible" option can speed up +the emulation noticeably, but it will be less accurate. This can be +fine for many games and other programs, but won't work e.g. for demos +using overscan or rasters. This is recommended only as a last resort. +
+ ++Roughly speaking, for Falcon DSP emulation with cycle exact 030 cache +emulation, one needs at least 3Ghz machine. For normal (unpatched) +Timer-D frequency on some specific cases (like demos with overscan 512 +color animations) one may need over 1GHz machine for ST/STE emulation, +but some rare demos may require over 1GHz machine even with Timer-D +patching. +
+ ++NOTE: Above options may cause some programs to work in correctly. +The Hatari Software Compatibility List +lists programs known to need real Falcon DSP emulation, Timer-D +frequency or accurate FDC timings. +
+ + +Emulator options
+ ++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. +
+ +Sound
+ ++Internal Hatari sound handling and the SDL_mixer sound thread +libALSA sound processing can account up to 1/3 of the Hatari CPU usage +in normal ST/STE emulation. Disabling sound will get rid of that. +Using low sound frequency or one matching your sound card may also help. +Best is if you disable also background music from the programs you run +in Hatari as this can significantly reduce the number of generated +interrupts. +
+ ++If program supports both ST and STE, use STE. Emulating DMA sound, is +more lightweight than interrupt heavy ST sound. +
+ ++If problem is occasional performance related audio glitches, increasing +the sound buffer size (with "--sound-buffer-size" option) may help, but +it increases sound latency. +
+ +Frame skipping
+ ++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. +
+ ++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, 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. +
+ +Zooming
++If you are not using frame skip, disabling zooming can have +noticeable improvement on performance. You can do this by specifying +suitably low "Max zoomed" resolution (--zoom +1 command line option sets it to 320x200). If you still want to +have a nice fullscreen mode, you should rather add the right resolution +mode-lines (e.g. "320x200") to your xorg.conf file. If you still want +to use zooming, disabling borders may help a bit. +
+ +Spec512 color handling
++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 either increase the threshold or disable the Spec512 mode handling +completely by zeroing the threshold for that with the +--spec512 0 option. +
+ +Statusbar and drive LED
++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. +
+ + +Measuring the performance
+ ++There are a couple of ways to monitor and measure Hatari performance. +
++By default Hatari has Statusbar visible and automatic frameskip +enabled. When Hatari has enough time that it can sleep a little each +frame, the statusbar frame skip ("FS") value keeps at zero. If Hatari +is completely busy, it will increase to the maximum specified +(automatic) frame skip value. +
++Hatari has also a facility to measure FPS i.e. Frames Per Second. +Enable frame skipping with +--fast-forward yes option +(or use the corresponding keyboard shortcut) and set +--log-level info. +Then after a while, press the "Pause" key. Whenever Hatari emulation +is paused, Hatari will output on console info on how many VBLs it +could show per second, along with some other numbers. +
++It depends on what you want to measure, but usually it is best to +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 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 +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 is best to +either have the test-case run automatically from the AUTO-folder or +given as memory snapshot to Hatari with the frame skip set equal to +the VBL count. +
++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 +at the same time you are making the measurements. +
+Appendix
Copying
+This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by the +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY -or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public -License for more details.
-You should have received a copy of the GNU General Public License -along with this program; if not, write to Free Software Foundation, -Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General +Public License for more details. ++You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software Foundation, +Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA +
The GNU Project and the Free Software Foundation | The GNU General Public License
+The GNU Project and the Free Software +Foundation | The +GNU General Public License
Introduction to Emulation
+Emulation via software is an art and Hatari is an example of this.
-Emulation is to make a computer behave like a (probably) completely different machine on the lowest possible niveau. -This includes CPU and custom chip emulation allowing software written for the emulated machine to be run without notice. -A good emulator will run most of the software intended for the emulated platform without trouble. +
Emulation is to make a computer behave like a (probably) completely +different machine on the lowest possible level. +This includes CPU and custom chip emulation allowing software written +for the emulated machine to be run without it noticing a difference.
-The key to emulation is to simply do those things with a software program, the emulator, that normally chips would perform. -So you have an CPU emulator that basically consists of a large loop that does exactly what the real thing would do: +The key to emulation is to simply do those things with a software +program, the emulator, that normally chips would perform. +So you have an CPU emulator that basically consists of a large loop +that does exactly what the real thing would do:
-
-
- fetch an instruction from virtual memory -
- interpret this instruction -
- fetch operands from the emulated registers and memory -
- perform the operation like addition or changing the program counter on a jump instruction -
- writes results back into the intended registers or memory locations -
- increment of the program counter and loop +
- fetch an instruction from virtual memory +
- interpret this instruction +
- fetch operands from the emulated registers and memory +
- perform the operation like addition or changing the program +counter on a jump instruction +
- writes results back into the intended registers or memory +locations +
- increment of the program counter and loop
-The typical von-Neumann CPU can be emulated very fast, stable and error-free using such a simple loop system. +The typical von-Neumann CPU can be emulated very fast, stable and +error-free using such a simple loop system.
-But in most cases the CPU emulation is the simplest part. Correct emulation of the various custom chips and hardware -parts of the emulated system is much trickier. +But in most cases the CPU emulation is the simplest part. Correct +emulation of the various custom chips and hardware parts of the +emulated system, and their proper synchronization, is much trickier.
- -Software compatibility list
-This is a little compilation of what Atari software does work in Hatari. It is by no means finished.
- -| Game | -Working | -Sound | -Comment | -
| Eliminator | -yes | -perfect | -- |
| Speedball | -yes | -perfect | -- |
| Xenon | -yes | -music ok - fx dodgy | -bullets and explosions sound weired | -
| Bubble Bobble | -yes | -- | - |
| F15 Strike Eagle 2 | -yes | -ok | -keyboard emulation seems to be dodgy | -
| Rick Dangerous | -yes | -perfect | -- |
| Slayer | -yes | -ok | -raster fx at highscore entry dodgy | -
| Lethal Xcess | -no | -- | crashes while loading, sync scrolling will not work properly | -
| Star Goose | -yes | -music ok - bullet sound dodgy | -- |
| Xenon 2 - Megablast | -yes | -nearly perfect (including sampled intro) | -- |
| Metal Mutant | -yes | -seems ok | -some color effects in the lower screen seem buggy | -
| Defenders Of The Earth | -yes | -- | - |
| Nebulus | -yes | -music ok; snowball, balls and trapdoors dodgy | -otherwise working to a playable extend | -
| Leander | -yes | -- | - |
| Navy Seals | -yes | -- | - |
| Armalyte | -yes | -- | - |
| Wings Of Death | -yes | -- | - |
| Alien World | -yes | -- | Only works with "--slowfdc" | -
| Fantasia (Demo by Dune) | -yes | -- | Only works with "--slowfdc" | -
| If pigs could fly (Demo by Syndicate) | -yes | -- | Only works with "--slowfdc" | -
| Application | -Working | -Comment | -
| DevPac 2.2 | -yes | -MonST crashy | -
| Turbo Assembler | -yes | -- |
| GFABASIC 3.6TT | -yes | -MENU.PRG does not like harddisks. Use diskimages for compiling. | -
| ST Basic | -yes | -- |
| Neochrome | -yes | -rasters sometimes unstable | -
| Crackart | -yes | -- |
| Tempus | -yes | -- |
| Sagrotan | -yes | -- |
| SidSound Designer | -yes | -- |
| MusicMon 2 | -yes | -- |
| Protracker | -yes | -- |
| Teradesk | -yes | -- |
| Qed | -yes | -- |
| Everest | -yes | -- |
| Speed Of Light | -yes | -- |
- -
| Matthias ArndtJuly 08 2004 | -