--- hatari/doc/manual.html 2019/04/09 08:57:12 1.1.1.20
+++ hatari/doc/manual.html 2019/04/09 08:58:26 1.1.1.21
@@ -64,7 +64,7 @@
General description
-Hatari is an Atari ST, STE, TT and Falcon emulator for Linux, OSX,
+Hatari is an Atari ST, STE, TT and Falcon emulator for Linux, *BSD, macOS,
Windows and other Systems which are supported by the SDL library.
The emulator is open source software and is distributed under the terms of the
GNU General
@@ -104,13 +104,12 @@ Unlike many other Atari ST emulators whi
environment for running GEM applications, Hatari tries to emulate the hardware
of a ST as close as possible so that it is able to run most of the old ST games
and demos. Of course you can run normal GEM applications with Hatari, too.
-Recent versions of Hatari even feature STE, Falcon and basic TT emulation.
Features
- 68000 - 68040 emulation via the UAE CPU core
- (68060 and MMU emulation only with the WinUAE CPU core)
+ (additional 68060 and MMU emulation only with the WinUAE CPU core)
- ST RAM size variable (from 512kiB up to 14MiB are possible)
- TT RAM size variable (from 0 up to 256MiB are possible)
- optional cartridge images for the ST ROM port
@@ -128,7 +127,7 @@ Recent versions of Hatari even feature S
- Printer port emulation on hardware level (print to file)
- RS232 emulation
- MIDI input/output/through emulation
- - Mega ST real time clock
+ - Mega ST(E) real time clock (for Mega-ST and Mega-STE mode)
- IKBD emulation (keyboard, mouse and joystick) with custom
keyboard mapping
- joystick emulation via cursor keys and joystick emulation via a
@@ -163,6 +162,10 @@ Recent versions of Hatari even feature S
- STE joypads
- TOS versions 1.06, 1.62, 2.05 and 2.06 (and EmuTOS) can be used in STE mode.
+
+Hatari can also emulate a Mega-STE, which had slightly different hardware
+compared to a normal STE (like a built-in real time clock chip).
+
Experimental TT hardware emulation
There is support for following additional TT features:
@@ -172,6 +175,10 @@ Recent versions of Hatari even feature S
RAM up to 14MiB (ST-RAM) and up to 256 MiB (TT-RAM)
Only TOS version 3.06 (and EmuTOS) can be used in TT mode.
+
+Note that TT emulation is incomplete – additional hardware like the
+second MFP and the SCC UARTs is not emulated yet.
+
Falcon hardware emulation
There is support for following additional Falcon features:
@@ -199,35 +206,14 @@ to be affected by them.
System requirements
- Hatari currently has the following minimum system requirements:
-
-
-In the course of time Hatari has successfully been tested by various people on
-the following systems:
+Hatari needs a fast machine (1 GHz or more for ST/STE emulation, > 2 GHz
+for Falcon emulation) which is running a POSIX compatible operating system
+(preferably GNU/Linux) that supports the SDL library.
+There are also some ports to other operating systems like macOS or Windows,
+but they are not used by the developers, so such builds are normally not very
+well tested.
-
- - Linux/i86 with Kernel 2.4.x and 2.6.x
- - Linux/PPC with Kernel 2.4.x and 2.6.x
- - BeOS/i86
- - Apple Mac OS X on PowerPC and i86
- - NetBSD 1.6 on i86
- - NetBSD on a Digital Alpha
- - FreeBSD 4.1 on an i486, FreeBSD 4.8 on a Pentium 4 and FreeBSD 5.1
- - OpenBSD 3.5 and 5.0
- - Solaris 8 on a SUN UltraSparc 1
- - Linux/ARM (oabi) on Sharp Zaurus SL-C760 PDA
- - Linux/ARM (eabi) on Nokia Maemo Internet Tablets and N900 phone
- - Windows XP
-
Compiling and running
@@ -374,11 +360,10 @@ to take effect.
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.
- (Note that autostarting a program might not work if you've also
- specified a floppy image for drive A: on command line or in config
- file which contains a desktop.inf/newdesk.inf/emutos.inf file on
- it.)
+
+(These arguments are shortcuts for "--disk-a", "--harddisk" and "--auto"
+options listed below.)
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
@@ -424,6 +409,10 @@ user configuration files
<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,
@@ -434,6 +423,9 @@ color
<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
@@ -442,6 +434,9 @@ mode
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)
@@ -473,6 +468,9 @@ for borders / zooming
<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
@@ -586,14 +584,16 @@ given port
<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>
+to <file> (Linux only)
--midi-out
<filename>
Enable MIDI support and read MIDI data
-from <file>
+from <file> (Linux only)
--rs232-in
<filename>
Enable serial port support and use
@@ -603,7 +603,7 @@ from <file>
Enable serial port support and use
<file> as the output device
-Disk options
+Floppy drive options
--drive-a
<bool>
Enable/disable drive A (default is on)
@@ -627,6 +627,18 @@ from <file>
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>
@@ -638,16 +650,27 @@ emulation
Specify whether new dir/filenames are forced to be
in upper or lower case with GEMDOS HD emulation. Off/upper/lower, off by default
--d, --harddrive
-<dir>
-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
+--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've 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 (seprately 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
+HD images partition tables)
--acsi
<file>
Emulate an ACSI hard drive with an image
@@ -672,7 +695,7 @@ incompatibilities)
-s, --memsize
<x>
Set amount of emulated RAM, x = 1 to 14
-MiB, or 0 for 512 KiB
+MiB, or 0 for 512 KiB. Other values are considered as a size in KiB
ROM options
-t,
@@ -715,8 +738,8 @@ CPU mode with better prefetch accuracy a
Misc system options
--machine <x>
-Select machine type (x = st, ste, tt or
-falcon)
+Select machine type (x = st, megast, ste,
+megaste, tt or falcon)
--blitter
<bool>
Enable blitter emulation (ST only)
@@ -734,9 +757,6 @@ interrupts.
Patch TOS and initialize the so-called
"memvalid" system variables to by-pass the memory test of TOS, so
that the system boots faster.
---rtc
-<bool>
-Enable real-time clock
Sound options
--mic
@@ -850,6 +870,11 @@ 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.
@@ -1485,9 +1510,9 @@ the screenshots and recorded videos.
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 Mac OS X).
+
"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).
@@ -1500,9 +1525,9 @@ the screenshots and recorded videos.
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 Mac OS X)
- together with the key, and the second type is directly activated by
- pressing a single key, without additional modifier key.
+ 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 Define buttons to
change the key for the shortcut. You'll be prompted to press the key
@@ -1621,7 +1646,7 @@ the selected file. ESC cancels the dialo
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 OS X, the Cmd key ⌘ is used instead.
+modifier key. On Mac macOS, the Cmd key ⌘ is used instead.
Below are listed the default shortcut key bindings:
@@ -1654,7 +1679,7 @@ Below are listed the default shortcut ke
| AltGr+c |
- coldreset the ST (same as the original power switch) |
+ cold reset the ST (same as the original power switch) |
| AltGr+d |
@@ -1706,6 +1731,10 @@ Below are listed the default shortcut ke
switch joystick type for joypad B |
+ | AltGr+b |
+ toggle borders on/off |
+
+
| AltGr+f or F11 |
toggle between fullscreen and windowed mode |
@@ -2314,7 +2343,7 @@ analyzing code that runs in the emulated
-On Unix (Linux / OSX) debugger uses Hatari's parent console window, so
+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
@@ -2326,10 +2355,19 @@ xterm -T "Hatari debug window" -e hatari
-To run debugger commands at Hatari startup, one can use the "--parse
-<file>" command line option. This is useful e.g. for debugging
-TOS or some demo startup code, or if you always want to use some
-specific debugger setup (breakpoints etc).
+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.
@@ -2372,15 +2410,18 @@ Generic commands:
cd ( ) : change directory
evaluate ( e) : evaluate an expression
help ( h) : print help
- history (hi) : show last CPU & DSP PC values & executed instructions
+ 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:
@@ -2395,7 +2436,7 @@ CPU commands:
savebin ( ) : save memory to a file
symbols ( ) : load CPU symbols & their addresses
step ( s) : single-step CPU
- next ( n) : step CPU, proceeding through subroutine calls
+ next ( n) : step CPU through subroutine calls / to given instruction type
cont ( c) : continue emulation / CPU single-stepping
DSP commands:
@@ -2407,7 +2448,7 @@ DSP commands:
dspprofile (dp) : profile DSP code
dspreg (dr) : read/write DSP registers
dspstep (ds) : single-step DSP
- dspnext (dn) : step DSP, proceeding through subroutine calls
+ dspnext (dn) : step DSP through subroutine calls / to given instruction type
dspcont (dc) : continue emulation / DSP single-stepping
@@ -2937,7 +2978,7 @@ indicates Blitter to be active (busy), t
In addition to loaded symbols, the debugger supports also setting
conditional breakpoints on values of some "virtual" variables listed
-by "b help". For example:
+by "variables" (v) command. For example:
- If you want the emulation to stop on the first instruction of
@@ -3081,19 +3122,29 @@ triggers) if you omit the instruction co
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 and exception calls. "ds" and "dn" commands
-do the same for DSP.
+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: BCC, BRA, DBCC, JMP
-- "subcall" matches subroutine calls: BSR, JSR
-- "subreturn" matches return from subroutine: RTD, RTR, RTS
-- "exception" matches exceptions: BKPT, ILLG, STOP, TRAP, TRAPV
-- "exreturn" matches return from exception: RTE
+- "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
@@ -3216,28 +3267,32 @@ When you're back in debugger, you can in
'profile' - profile CPU code
Usage: profile <subcommand> [parameter]
- Subcommands:
- - on
+ Subcommands:
+ - on
- off
- counts [count]
- cycles [count]
- - misses [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
+ 'on' ¨ 'off' enable and disable profiling. Data is collected
until debugger is entered again at which point you get profiling
statistics ('stats') summary.
Then you can ask for list of the PC addresses, sorted either by
- execution 'counts', used 'cycles' or cache 'misses'. First can
- be limited just to named addresses with 'symbols'. Optional
- count will limit how many items will be shown.
+ 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
@@ -3279,15 +3334,16 @@ around top addresses:
> profile addresses 0xe06f04
# disassembly with profile data:
-# <instructions percentage>% (<sum of instructions>, <sum of cycles>, <sum of i-cache misses>)
-$e06f04 : bra.s $e06f10 0.00% (48, 576, 0)
-$e06f06 : move.b $fffffa01.w,d1 12.11% (555708, 8902068, 0)
-$e06f0a : btst #5,d1 12.11% (555708, 6685268, 0)
-$e06f0e : beq.s $e06f1e 12.11% (555708, 4457312, 0)
-$e06f10 : move.l $4ba,d1 12.11% (555724, 11125668, 0)
-$e06f16 : cmp.l d1,d0 12.11% (555724, 4461708, 0)
-$e06f18 : bgt.s $e06f06 12.11% (555724, 4455040, 0)
-$e06f1a : moveq #1,d0 0.00% (16, 64, 0)
+# <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.
@@ -3362,6 +3418,11 @@ Finalizing costs for 12 non-returned fun
("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:
@@ -4045,6 +4106,19 @@ Please see also Profiling section for more info.
+
+
- Finding where a program or the OS is stuck
- Profiling tells from which addresses CPU is executing the instructions:
@@ -4131,10 +4205,10 @@ mode, so try to avoid 24 bits per pixel
-On OSX, frame skipping, zooming and drive LED options (listed below)
-seem to have a large effect on performance in the windowed mode.
-This is apparently due to issues in the SDL OSX backend and how OSX
-itself composites non-fullscreen window contents. OSX uses always
+On macOS with SDL 1.2, 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. MacOS uses always
32-bit mode.
@@ -4256,9 +4330,9 @@ Also, if your monitor refresh frequency
Hatari monitor frequency (e.g. LCD monitors usually use 60Hz whereas
Atari monochrome monitor uses 71Hz), you should use frameskip of one.
The reason is that if your SDL library uses VSync to synchronize the
-output to screen (like OSX one?), with zero frame skip that forces the
-emulation to run slower than a real Atari. If SDL doesn't use VSync,
-Hatari does redundant work to convert frames you can't see.
+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