@@ -1377,7 +1629,7 @@ that you have made.
compatible. Use 16MHz for Mega STE and Falcon emulation.
The CPU in the TT was clocked with 32 MHz.
-With the "Slower but more compatible CPU" option, you can enable
the emulation of 68k address errors and the 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.
@@ -1386,7 +1638,7 @@ that you have made.
fake it or completely disable it. 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). So if you have a slow host CPU, you can try if your
- Falcon program also runs with DSP disabled or in "dummy" mode.
+ Falcon program also runs with DSP disabled or in "dummy" mode.
Note that you can not change this option while the DSP based program already
runs.
@@ -1394,7 +1646,7 @@ that you have made.
chip that accelerates some graphical operations. This switch only toggles the
Blitter in plain ST mode. In STE mode, the Blitter is always enabled (since all
STEs have been sold with a Blitter chip).
-If you enable the "Real time clock emulation" switch, a RTC will
be emulated based on the time of the host computer. Note that you need at least
TOS 1.02 for proper RTC emulation, TOS 1.00 does not support this.
The Timer-D patch changes the Timer-D initialization from TOS. TOS uses
@@ -1402,9 +1654,11 @@ that you have made.
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 then.
-
Select if you want to use slow FDC (Floppy Disk Controller) emulation.
- "Slow floppy access" is normally not required, except for some few
+ "Slow floppy access" is normally not required, except for some few
slideshows / intros which run too fast without this option.
- You can select a harddrive image for ACSI or IDE hard drive emulation via
- image file here or you may select a directory of your local filesystem to be
- emulated as the harddrive of the emulated system.
+ You can select a harddrive image for ACSI, IDE master or slave hard drive
+ emulation via image file here or you may select a directory of your local
+ filesystem to be emulated as the harddrive of the emulated system.
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.
+ This option is checked by default if you specify a harddrive image or
+ a directory via the command line.
+
+
+ Removing the check from the "Allow GEMDOS drive modification" option
+ will prevent Atari programs from modifying the files in GEMDOS HDD
+ emulation directory or creating new files under it.
Note that for IDE hard disk emulation you also need a TOS version >= 2.05.
@@ -1574,7 +1837,7 @@ which are plugged in the enhanced joysti
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".
+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
@@ -1583,85 +1846,126 @@ the keys for up, down, left, right and f
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.
-
- Check "Fullscreen" to run Hatari fullscreen, default is windowed.
+ 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.
- "Use Borders" toggles the displaying of the borders around the ST
- screen. Some few demos/games use the borders for displaying additional
- graphics. However, when you enable this option, it increases CPU computing
- time, so you should not enable it if you have a slow computer.
- Please note that this option also only affects the ST and STE mode, TT and
- Falcon modes are always displayed without borders.
+ "Show ST/STE borders" toggles the displaying of the borders around the ST /
+ STE screen. 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.
+ This option affects only the ST and STE modes, TT and Falcon modes are
+ always displayed without borders.
- "Zoom ST-Low res." controls whether Hatari doubles the low
- resolutions. For example Hatari then zooms the ST low resolution 320x200 to
- 640x400 and it doubles 384x267 (ST low with borders) to 768x534.
- Note that zooming also takes a lot of CPU computing time and should not be
- enabled on slow computers.
+Extended VDI resolutions will emulate a sort of extended graphics
+card in the emulated ST which give you larger resolutions with a higher
+colordepth for GEM. Select a resolution and color depth. Check to
+activate. It will disable all other video options mentioned above.
+Uncheck to get back to a normal ST behaviour.
+Note: Using an extended resolution will only work with GEM
+conformant applications. 99% of all games and demos will not run if you
+activate any extended resolution here.
+
+
+
- "Statusbar" toggles the statusbar at the bottom of the screen.
- The statusbar shows the floppy drive LEDs, the current frameskip value,
- the machine type including TOS version and memory size, and whether
- recording is currently active.
+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 set to speed up the emulator
+ 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
+ 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!
- 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.
+ "Statusbar" toggles the statusbar at the bottom of the screen.
+ The statusbar shows the floppy drive LEDs, the current frameskip value,
+ the machine type including TOS version and memory size, and whether
+ recording is currently active.
-Extended GEM resolutions will emulate some sort of extended graphics
-card in the emulated ST giving you larger resolutions and a higher
-colordepth in GEM. Select a resolution and color depth. Check to
-activate. It will disable all other video options mentioned above.
-Uncheck to get back to a normal ST behaviour.
-Note: Using an extended resolution will only work with GEM
-conformant applications. 99% of all games and demos will not run if you
-activate any extended resolution here.
+"Max zoomed" option controls up to which size Hatari tries to scale
+the Atari resolutions and how much of the borders (enabled in Atari
+Monitor dialog) will be shown. There are several limitations in
+this:
-
+You should set these values to a size that suits best your monitor
+resolution. It's intended to help in getting Hatari to best use your
+monitor space on a windowed mode and in fullscreen avoiding "fuzzy"
+scaling either by Hatari or 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.
+
+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
+ 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 Mac OS X).
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"
+ 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.
@@ -1750,9 +2054,9 @@ device files for serial input and output
Click on
+NOTE: Problems with simultenous keypresses most likely aren't an
+issue in Hatari as many modern keyboards report/support only three
+simultenous key presses (or even just two depending on which keys
+are in question). Expensive gaming keyboards support more.
+
Emulated mouse
@@ -2067,109 +2376,202 @@ Please note that changing the HD-image o
the emulated Atari since it is not possible to switch the hard disk
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.
+
GEMDOS based hard disk emulation
-With the GEMDOS based drive emulation, you can easily "mount" a
+
+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!
-
-There are also some known limitations which are due to the way the GEMDOS
-drive emulation is implemented: First, it is not possible to use a cartridge
-image together with GEMDOS drive emulation at the same time.
-Second, the GEMDOS HD emulation does not work very well with TOS
-1.00 and 1.02. So you should use at least TOS 1.04 if you want
-to use the GEMDOS HD emulation.
+filenames i.e. file and folders names shouldn't contain invalid GEMDOS
+filename characters and their length shouldn't exceed the 8+3 file name
+length limit.
+
+
+If you provide --harddisk option
+a directory containing only single letter subdirectories, each of
+these subdirectories will be treated as a separate partition, otherwise
+the given directory itself will be assigned to drive "C:". In the
+multiple partition case, the letters used as the subdirectory names
+will determine to which drives/partitions they're assigned.
+
+
+GEMDOS drive emulation is an easy way to share files between the
+host system and the emulated Atari, but there are also some known
+limitations which are due to the way the GEMDOS drive emulation is
+implemented:
+
+
+- It is not possible to use a cartridge image at the same time
+with the GEMDOS drive emulation (Hatari has it's own cartridge code
+that is used for GEMDOS emulation).
+- As MiNT installs its own GEMDOS handler, it doesn't work with
+the GEMDOS drive emulation. MiNT needs to be booted from a real hard
+disk image.
+- GEMDOS drive emulation conflicts with the ACSI and IDE harddisk images.
+If you want to use GEMDOS HD emulation and ACSI/IDE disk images together,
+use a multiple partition GEMDOS emulation setup and select the partition
+subdirectories (letters) so that they don't conflict with the ACSI/IDE
+drive partitions (letters). With HD Driver you have also another option,
+see Using HD Driver
+with GEMDOS partitions.
+- The GEMDOS drive emulation does not work (very well) with TOS
+1.00 and 1.02. Use at least TOS 1.04 if you want the GEMDOS drive
+emulation to work properly.
+
+
+So, if your programs complain that they could not find/read/write
+files on the GEMDOS emulated drive, you should try to copy them to a
+floppy disk image or a real hard disk image!
-
ACSI hard disk 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 (e.g. from the Hatari website).
-Please note that AHDI 5.0 is currently the only hard disk driver
-that is officially supported. Other hard disk drivers might not work.
-
-
-To create a new ACSI hard disk image, you can start with an empty image that
-you have for example created with the following command:
-dd if=/dev/zero of=hd.img bs=512 count=xxx.
-Then copy the complete AHDI 5.0 package to a floppy disk image, and enable
-this floppy disk image and the fresh hard disk image in the emulator.
-Start HDX.PRG from the floppy disk and format and partition the hard disk
-with this tool. When you're finished, you have to restart the emulated system,
-run AHDI.PRG from the floppy disk and HINSTALL.PRG afterwards.
-With HINSTALL.PRG you can install the hard disk driver to the fresh HD image,
-so you can directly boot from the hard disk image in the future.
+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).
+
+
+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's 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.
IDE hard disk emulation
-Create an empty image file with the size of your choice with:
+
+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 formatting 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 (named "cecile.st") e.g. with:
-zip2st.sh cecile.zip.
+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 hd.img cecile.st,
-warm up your French language skills, start the Cecile hard disk driver
-CECILE.PRG, then use the tool CC_TOOLS.APP to partition your hard disk
-image: click to "Partition", select "Hatari IDE disk" and set suitable
-partition size. Then click "Valider".
+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:
-select "Installer" from main menu and save the Cecile driver to the
+Click the "Installer" button and save the Cecile driver to the
1st partition on "Hatari IDE disk". If you want to also use your HD
image in ST/STE mode, you need to get and install AHDI 6 driver on it
-instead (see "ASCI hard disk emulation" section for AHDI usage
-instructions).
+instead (see ASCI hard disk
+emulation section).
Then you can boot from your hard disk image by simply specifying it
-with the --ide parameter.
+with the --ide-master parameter.
-Accessing disk image partitions outside of Hatari
+Moving files
+to/from hard disk images
+
+Moving files to and from Atari hard disk images can be done
+either through GEMDOS 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's fine for the IDE/ACSI partitions to be first, you can use
+hard disk images with AHDI or Cecile driver and a multipartition
+GEMDOS setup as described in above sections. If you want to boot from
+a GEMDOS 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.
+
+Using HD Driver
+with GEMDOS partitions
+
+Uwe Seimet's HD
+Driver works fine with both the Hatari GEMDOS partitions and normal
+hard disk images. However, it doesn't work with EmuTOS so you need
+real TOS (at least version v1.04).
+
+
+First copy the HDDRIVER.PRG binary into your GEMDOS drive 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 directory, for example like this:
+"hatari --harddisk 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 partition (with
+some write slowndowns 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 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 --harddisk gemdos-hd/ hd-driver-floppy.st".
+
+
+
+Accessing
+HDD image partitions outside of Hatari
+
-If you want to access the partitions also outside the emulation,
-the disk image needs to have a DOS partition table. The
-atari-hd-image script included
+If you want to access the harddisk 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, Centek's Cecile (mentioned above) and Uwe Seimet's
-HD Driver
-(demo) work fine with them. E.g. AHDI and CBHD don't.
+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.
-Note also that plain EmuTOS supports only ACSI and the drivers support
-only IDE (emulation). Cecile needs TT or Falcon and HD driver doesn't
-work with EmuTOS or TOS4. To summarise; if ASCI emulation and EmuTOS
-are enough, use those. 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).
+Note that plain EmuTOS supports only ACSI and the listed HD drivers
+support only IDE (emulation). Cecile needs TT or Falcon and HD Driver
+doesn't work with EmuTOS. To summarise; if ASCI emulation and
+EmuTOS are enough, use those. 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
@@ -2191,10 +2593,11 @@ drive c: file="/home/user/hatari/hd.img"
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:
+the environment like this ("::" refers to the drive image given with
+the "-i" option):
-MTOOLS_NO_VFAT=1 mcopy foobar.txt c:
+MTOOLS_NO_VFAT=1 mcopy -spmv -i hd.img files/* ::
Using a loopback device
@@ -2234,78 +2637,134 @@ the disk image from Hatari:
Hatari has a built-in debugging interface which can be used for
-analyzing the program that runs in the emulated system. The debugger
-uses Hatari's parent console window, so make sure you run Hatari from
-the command line when you want to use the debugger. To invoke
-the debugger, press the AltGr + Pause key
-combination.
-
+analyzing code that runs in the emulated system. To invoke the
+debugger, press the AltGr + Pause
+key combination.
+
-If you start Hatari with the "-D" command line option, m68k
-exceptions will automatically invoke the debugger. You can toggle
-this also later from the debugger with the "setopt -D"
+If you start Hatari with the "-D" command line option, m68k
+exceptions will automatically invoke the debugger. You can
+toggle this also later from the debugger with the "setopt -D"
command.
-When entering values to the debugger in other number bases than the
-default/selected one, they need to be prefixed with a character
-indicating this. For decimals it's "#" (#15), for
-hexadecimals "$" ($F), and for binary values it's
-"%" (%1111). By default the debugger expects all values
-without a prefix to be decimals, but you can change the default number
-base with the "value" command.
+The debugger uses Hatari's parent console window, so make sure you run
+Hatari from the command line when you want to use the debugger. On
+Linux you can add for example an icon to your desktop that runs: xterm -T "Hatari debug window" -e hatari.
+
+General debugger use
+
-At the debugger prompt, type "help" to get a list of all
+At the debugger prompt, type "help" to get a list of all
the available commands and their shortcuts:
-Available commands:
- dspaddress (da) : toggle or list (traditional) DSP address breakpoints
- dspbreak (db) : set/remove/list DSP register/RAM condition breakpoints
- dspdisasm (dd) : disassemble DSP code
- dspmemdump (dm) : dump DSP memory
- dspreg (dr) : read/write DSP registers
- dspcont (dc) : continue emulation / DSP single-stepping
- address ( a) : toggle or list (traditional) CPU address breakpoints
- breakpoint ( b) : set/remove/list register/RAM condition breakpoints
+Generic commands:
+ cd ( ) : change directory
+ evaluate ( e) : evaluate an expression
+ exec ( ) : execute a shell command
+ help ( h) : print help
+ info ( i) : show machine/OS information
+ lock ( ) : lock info to show on entering debugger
+ logfile ( f) : open or close log file
+ parse ( p) : get debugger commands from file
+ setopt ( o) : set Hatari command line and debugger options
+ stateload ( ) : restore emulation state
+ statesave ( ) : save emulation state
+ trace ( t) : select Hatari tracing settings
+ 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
cpureg ( r) : dump register values or set register to value
memdump ( m) : dump memory
memwrite ( w) : write bytes to memory
- logfile ( f) : open or close log file
loadbin ( l) : load a file into memory
savebin ( s) : save memory to a file
- setopt ( o) : set Hatari command line options
- value ( v) : set number base / show value in other number bases
+ symbols ( ) : load CPU symbols & their addresses
cont ( c) : continue emulation / CPU single-stepping
- quit ( q) : quit emulator
- help ( h) : print help
+
+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
+ dspreg (dr) : read/write DSP registers
+ dspcont (dc) : continue emulation / DSP single-stepping
-In the beginning, probably the most interesting commands are
-"m" and "d" for dumping and disassembling memory
-regions.
+When entering numbers to the debugger commands in other number bases
+than the default/selected one, they need to be prefixed with a
+character indicating this. For decimals this prefix is "#" (#15),
+for hexadecimals "$" ($F), and for binary values it's "%" (%1111).
+By default the debugger expects all numbers without a prefix to be
+decimals, but you can change the default number base with the "setopt"
+command, just give it the desired default number base (bin/dec/hex).
+
+
+
+Instead of a number, you can also use an expression, by surrounding
+it with quotes (""). An expression can contain calculations with
+register and symbol values in addition to numbers. For example to
+give a sum of A0 and D0 register values to a command, use "a0+d0".
+
+
+
+Note that within expressions parenthesis are used to change
+the order of precendence, they cannot be used for
+indicating indirect addressing like with conditional breakpoints
+(explained below). Even when using expressions within conditional
+breakpoints.
+And when using the hexadecimal number base, remember still to prefix
+with '$' hexadesimal numbers that can be confused with register names
+(a0-7, d0-7), otherwise results from expressions and conditional
+breakpoints can be quite surprising.
+
+
+
+Expressions are always evaluated before being given to a command.
+Expressions don't need to be quoted for the "evaluate" or "address"
+commands as those always interpret their results as expressions.
+
+
+
+With command argument completion (see build
+notes), result from last "evaluate" command can 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 [address]
+Usage: m [start address-[end address]]
dump memory at address or continue dump from previous address.
> help disasm
'disasm' or 'd' - disassemble from PC, or given address
-Usage: d [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 postition is available.
+ position or from current PC if no last position is available.
-> d
+> disasm
0000aa6e: 2f08 0241 0fff 207c 00fe MOVE.L A0,-(A7)
0000aa70: 0241 0fff 207c 00fe 78c0 AND.W #$0fff,D1
0000aa74: 207c 00fe 78c0 2070 1000 MOVEA.L #$00fe78c0,A0
@@ -2314,87 +2773,254 @@ Usage: d [address]
-Hatari has two kinds of breakpoints. First, there are the fast and
-simple address breakpoints which trigger when the CPU (or DSP) program counter
-hits a given address. Use "a" (or "da" for the DSP) to
-manage them. Then there are the conditional breakpoints which are a little bit
-slower but can handle more complex break conditions. Use "b" (or
-"db" for the DSP) to manage them. "b help" explains
-the syntax:
+You can use the "info" command to see state of specific sets of HW
+registers ("info videl") or Atari OS structures ("info basepage").
+
+
+
+By using the "lock" command, you can ask Hatari to show above kind of
+information whenever you enter the debugger ("lock disasm"). With the
+"regaddr" subcommand, it can show also disassembly or memory dump of
+an address pointed by a given register ("lock regaddr disasm a0"). Of
+the DSP registers, only Rx ones are valid for this subcommand. To
+disable showing of this extra information, use "lock default".
+
+
+Debug symbols
+
+
+You can load symbol name/address information from a file to the
+debugger with the "symbols" command (and with "dspsymbols" for DSP).
+These symbolic names can be used in expressions and all breakpoints.
+They also show up in the "disasm" command output.
+
+
+The symbols file format is following:
+
+e01034 T random
+e01076 T kbdvbase
+e0107e T supexec
+
+
+Where 'T' means text (code), 'D' means data and 'B' BSS section type
+of address. The symbol hexadecimal address, type letter and name are
+separated by white space. Empty lines and lines starting with '#'
+(comments) are ignored.
+
+
+
+AHCC C-compiler can provide a symbol file suitable for this with its
+"-n 'nm' list" option (not enabled by default). If you're reverse
+engineering some code, you could just create your own symbols file to
+help in debugging it later.
+
+
+
+If you're debugging normal TOS/GEM programs instead of code loaded
+into fixed address (like EmuTOS), you can use the "info basepage"
+command to find out the text segment address to which the program code
+has been loaded into, and then load symbols so that their addresses
+are offset by the text segment address:
+
+
+> info basepage
+Process basepage information:
+- TPA start : 0x01a1bc
+- TPA end +1 : 0x7da700
+- Text segment : 0x01a2bc
+- Text size : 0xe1e0
+- Data segment : 0x02849c
+- Data size : 0x1b76
+- BSS segment : 0x02a012
+- BSS size : 0x3750
+- Process DTA : 0x01a23c
+- Parent basepage: 0x00e91c
+- Environment : 0x01a1ae
+'PATH='
+'C:\'
+- Command argslen: 0
+> symbols calc.sym 0x01a2bc
+
+
+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
+
+
+
+(Address breakpoints are just wrappers for conditional breakpoints so
+you need to use "b" command to remove or list them.)
+
+
+
+Then there are the conditional breakpoints which can handle much more
+complex break conditions; they can track changes to register and
+memory values with bitmasks, include multiple conditions for
+triggering a breakpoint and so on. Use "b" (or "db" for the DSP)
+to manage them. "b help" explains the syntax:
-breakpoint = <expression> [ && <expression> [ && <expression> ] ... ]
-expression = <value>[.mode] [& <number>] <condition> <value>[.mode]
+breakpoint = <condition> [ && <condition> ... ] [option]
+condition = <value>[.mode] [& <number>] <comparison> <value>[.mode]
where:
- value = [(] <register-name | hatari-variable | number> [)]
- number = [#|$|%]<digits>
- condition = '<' | '>' | '=' | '!'
- addressing mode (width) = 'b' | 'w' | 'l'
- addressing mode (space) = 'p' | 'x' | 'y'
+ value = [(] <register/symbol/variable name | number> [)]
+ number = [#|$|%]<digits>
+ comparison = '<' | '>' | '=' | '!'
+ addressing mode (width) = 'b' | 'w' | 'l'
+ addressing mode (space) = 'p' | 'x' | 'y'
+ option = : <count> | 'once' | 'trace'
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.
+used value will be read from the memory address pointed by it. Note
+that this value is checked at run-time whereas quoted expressions
+(mentioned above, please read!) are evaluated already when adding a
+breakpoint. For example, to break when value in adress pointed by A0
+matches the value currently in D0, one would use:
+
+> b (a0) = "d0"
+
+
-M68k addresses can have byte ("b"), word ("w") or
-long ("l", default) width. DSP addresses belong to different
-address spaces: "P", "X" or "Y". Note
-that on DSP only R0-R7 registers can be used for memory addressing.
+M68k addresses can have byte ("b"), word ("w") or long ("l", default)
+width. DSP addresses belong to different address spaces: "P", "X" or
+"Y". Note that on DSP only R0-R7 registers can be used for memory
+addressing.
Examples:
-pc = $64543 && ($ff820).w & 3 = (a0) && d0 = %1100
-(r0).x = 1 && (r0).y = 2
-
+b (r0).x = 1 && (r0).y = 2
+b pc = $64543 && ($ff820).w & 3 = (a0) && d0 = %1100
+
-The debugger supports also setting breakpoints on values of some
-internal Hatari variables (listed by "b help"). For example
+The debugger supports also setting conditional breakpoints on values
+of some internal Hatari variables (listed by "b help"). For example
if you want to stop at a specific cycle within a frame (that is, PC
-relative to the current VBL/HBL in cycles), set breakpoints to specific
-"HBL" and "LineCycles" variable values.
+relative to the current VBL/HBL in cycles), set breakpoints to
+specific "HBL" and "LineCycles" variable values. The "e" command
+can be used to calculate suitable register and variable values.
+
+
+
+As a convenience, if the value expressions on both sides of the
+comparison are exactly the same, right side is replaced with its
+current value. For inequality ('!') comparison, conditional breakpoint
+tracks all further changes for the given address/register expression,
+this can be used for example to find out all value changes in a given
+memory address (see examples below).
+
-After analyzing and/or setting new breakpoints, you can continue the emulation
-with the "c" command. You can continue for a given number of
-CPU instructions (or DSP instructions when "dc" is used), or
-you can continue forever (until a breakpoint triggers) if you omit the
+There are also several options that you can use with both breakpoint
+types. ":trace" option will make breakpoint to print out the tracked
+value instead of breaking. This can be useful e.g. when tracking
+changes to some register like in:
+
+
+> b ($ffff9202).w ! ($ffff9202).w :trace
+
+
+
+":once" option that removes breakpoint after hit can be useful when one
+wants to get out of a loop (when at the instruction that branches back
+to loop start) or just to get to a specific point in code:
+
+
+> b pc > pc :once
+> a some_symbol :once
+
+
+
+Whereas giving count (like ":2") as option will break only on every
+<count> hit.
+
+
+
+After analyzing and/or setting new breakpoints, you can continue the
+emulation with the "c" command. You can continue for a given number of
+CPU instructions (or DSP instructions when "dc" is used), or you can
+continue forever (until a breakpoint triggers) if you omit the
instruction count.
+Tracing
+
-By the way, if you want to continue with real-time disassembling, you
-can enable it by typing "setopt --trace cpu_disasm" at the
-debugger prompt. Disable it with "setopt --trace none" when
-you enter the debugger again. "--trace help" can be used to
-list all the supported trace points. (Similar things can be done even
-from a program within the emulation if you enable Hatari
-"--bios-intercept" option and call XBios 255 from
-the program with a suitable command line string.)
+If you want to continue with real-time disassembling, you can enable it
+with "trace cpu_disasm" at the debugger prompt before continuing.
+
+
+Disable tracing with "trace none" when you enter the debugger again.
+"trace help" (or TAB) can be used to list all the supported trace points.
+
+
+Because Hatari normally emulates things at the hardware level, tracing
+Atari OS functions requires setting additional Hatari options which
+tell it to intercept higher level functionality:
+
+- BIOS and XBIOS tracing require enabling bios intercepting
+- GEMDOS tracing use of the GEMDOS harddisk emulation
+- VDI tracing use of a VDI graphics mode
+
+
+Tracing options can be set even from a program within the emulation
+if you enable Hatari "--bios-intercept" option and call XBios 255 from
+the program with a suitable Hatari command line string.
+
+
+Note that the trace output file can be set only when Hatari starts,
+it cannot be changed from within the debugger (or emulation).
+Build notes
+
Lastly, the debugger is much nicer to use with the command line
-editing support. If you're building Hatari yourself, please make sure
-that you have the GNU readline development files installed (on Debian
-/ Ubuntu these come from the libreadline5-dev package). Otherwise
-this doesn't get enabled when you configure Hatari.
+history, editing and especially with the command, command argument and
+symbol name completion support. If you're building Hatari yourself,
+please make sure that you have the GNU readline development files
+installed (on Debian / Ubuntu these come from the libreadline5-dev
+package). Otherwise this doesn't get enabled when you configure
+Hatari.
+
+
+
+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.
+
+
Improving Hatari performance
Unless you've 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.
+performance. Using GCC -O3 option instead of -O2 can give minor
+(5-10%) performance improvements for things (demos) that use very
+heavily interrupts.
However, Hatari can be sped up considerably by giving up some
@@ -2414,7 +3040,7 @@ an effect!
DSP
-Emulating the DSP is performance-wise several times more demanding
+Emulating the Falcon DSP is performance-wise several times more demanding
than emulating the m68k; DSP runs at higher frequency, executes many
instructions for each m68k instruction and emulation isn't as mature
and optimized. Unless some program needs DSP, none or
@@ -2422,17 +3048,19 @@ and optimized. Unless some program need
that do use DSP, many use it only for background music and work
fine without the real DSP emulation.
+
Timer-D
The single largest factor contributing to general Hatari emulation
performance is the handling of interrupts. Enabling Timer-D patching
-option (about) doubles Hatari performance as it significantly reduces
-the number of interrupts generated by the emulated Atari machine.
-Using this has adverse effect only for very rare programs.
+option (about) doubles Hatari ST/STE emulation performance as it
+significantly reduces the number of interrupts generated by the emulated
+Atari machine. Using this has adverse effect only for very rare programs.
+
Compatible CPU
-After the DSP and Timer-D interrupts, m68k emulation takes most time.
+After the DSP and interrupts, m68k emulation takes most time.
Disabling the "Slower but more compatible CPU" option will speed up
the emulation a lot, but it won't anymore be cycle accurate. This can
be fine for many games and other programs, but won't work e.g. for demos
@@ -2440,15 +3068,20 @@ using overscan or rasters.
-Roughly speaking, for DSP emulation, one needs at least 2Ghz machine;
-for normal (unpatched) Timer-D frequency on some specific cases (like
+Roughly speaking, for DSP emulation, one needs at least 2Ghz 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 Compatible CPU one needs at least 1/2Ghz machine.
+machine, but some rare ST/STE demos may require over 1GHz machine even
+with Timer-D patching. For "Compatible CPU" one needs at least 1/2Ghz
+machine.
+
-Above options may cause some programs not to work correctly.
-The Hatari Software Compatibility List lists
-programs known to need real DSP emulation or Timer-D frequency.
+NOTE: Above options may cause some programs not to work correctly.
+The Hatari Software Compatibility List
+lists programs known to need real real Falcon DSP emulation or Timer-D
+frequency. Disabling "Compatible CPU" option is recommended only as
+a last resort.
@@ -2465,12 +3098,13 @@ be toggled at run-time without rebooting
Internal Hatari sound handling and the SDL_mixer sound thread
libALSA sound processing can account up to 1/3 of the Hatari CPU usage
-(depending on other options you're using). 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.
+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.
+
Frame skipping
Screen rendering can take noticeable amount of CPU time. The default
@@ -2478,21 +3112,25 @@ Hatari "auto" frame skipping should be u
reason not to. It will skip converting and showing some of the frames
if there's not enough time for them. If your monitor refresh frequency
is lower than the selected Hatari monitor frequency (e.g. LCD monitors
-usually use 60Hz whereas Atari monochrome monitor uses 72Hz), you
+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.
-Low-rez zooming
+
+Zooming
If you are not using frame skip, disabling zooming can have
-noticeable improvement on performance. 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.
+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
@@ -2501,6 +3139,7 @@ screens and you care more e.g. from the
can disable the Spec512 mode handling by zeroing the threshold for that
with the --spec512 0 option.
+
Statusbar and drive LED
If your version of libSDL uses VSync to synchronize the screen
@@ -2538,8 +3177,8 @@ Hatari has also a facility to measure FP
Just enable the --fast-forward option
on command line (or use the corresponding keyboard shortcut), and
after a while, press the "Pause" key. Whenever Hatari emulation is
-paused, Hatari will show how many VBLs it could show per second along
-with some other numbers.
+paused, Hatari will output on console how many VBLs it could show per
+second along with some other numbers.
It depends on what you want to measure, but usually it's best to
@@ -2555,10 +3194,10 @@ call, only the time spent by the Hatari
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 in fast forward mode before it exits. In this
-case it's 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.
+VBLs Hatari should run before it exits. In this case it's 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 the numbers can fluctuate quite a bit, especially
@@ -2639,7 +3278,7 @@ parts of the emulated system is much tri
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"
border="0" height="31" width="88">
-
+
+
+