--- hatari/doc/manual.html 2019/04/09 08:52:20 1.1.1.16 +++ hatari/doc/manual.html 2019/04/09 08:58:26 1.1.1.21 @@ -1,15 +1,13 @@ - - + + Hatari User's Manual - - - - - - + content="User's manual for the Atari ST emulator Hatari" /> + + + + + @@ -55,105 +64,30 @@

Hatari User's Manual

-Version 1.6.2 +Version 2.1.0, February 2018

Manual written by: Thomas Huth, Matthias Arndt & Eero Tamminen

-Hatari on the WWW: http://hatari.tuxfamily.org/ +Hatari on the WWW: + +http://hatari.tuxfamily.org/ +

-

Index

- +

Index

+
+ +
-

Introduction

+

Introduction

-

General description

+

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 @@ -170,14 +104,14 @@ 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

+

Features

-

STE hardware emulation

There is support for following additional STE features:

+

+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:

+

+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:

@@ -261,41 +204,20 @@ Software Compatibility List for whic to be affected by them.

-

System requirements

- -

Hatari currently has the following minimum system requirements:

- +

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.

- -

Compiling and running

+

Compiling and running

-

Compiling Hatari

+

Compiling Hatari

Required:

@@ -2204,22 +1496,23 @@ Selecting "Crop statusbar" option will l the screenshots and recorded videos.

-

The Keyboard Dialog

+

The Keyboard Dialog

-Hatari's GUI - the keyboard dialog + Hatari's GUI - 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 + 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).

@@ -2229,17 +1522,34 @@ the screenshots and recorded videos. at the supplied example mapfile (keymap-sample.txt) to see how to create your own keyboard mapping.

- 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. To avoid this you can - disable the key repetition in fast forward mode here. + 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 Define 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

+

The Sound Dialog

-Hatari's GUI - the sound dialog + Hatari's GUI - the sound dialog

Here you can control the sound subsystem.

@@ -2272,20 +1582,21 @@ for accurate sound's emulation.

-

The Devices Dialog

+

The Devices Dialog

-Hatari's GUI - the device dialog + Hatari's GUI - the device dialog
-

Check the first checkmark to enable experimental printer support. -See the Emulated printer section for +

Check the first checkmark to enable printer support. +See the Emulated printer section for details.

As Hatari currently only supports printing to file, click on Browse to select the file to print to. You can enter a new filename as well.

-

Check the second checkmark to enable experimental RS232 support. +

Check the second checkmark to enable RS232 support. The RS232 device is configured according to the settings of the emulated RS232 of the Atari ST. This means Hatari will automatically use baudrate and handshaking as configured for the @@ -2294,145 +1605,195 @@ emulated ST.

device files for serial input and output. On Linux a good choice is /dev/ttyS0 or /dev/ttyS1.

-

Check the third checkmark to enable experimental MIDI support. +

Check the third checkmark to enable MIDI support. Click on Browse 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 -synthetizing on Linux (using Alsa) if your sound card/driver doesn't +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

+

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:

+ + + +

Keyboard shortcuts during emulation

While the emulator is running, you can activate or toggle various -features via Hatari keyboard shortcuts. Below are listed the default -shortcut key bindings:

- - +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:

+
+ - - + + + + + + + + + + + + + + + + + + + + + + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + +
ShortcutPurposeShortcutPurpose
AltGr+arecord animation
AltGr+ggrab a screenshot
AltGr+iboss key: leave full screen mode, pause Hatari + and iconify its window
AltGr+m(un-)lock the mouse into the window
AltGr+r(warm) reset the ST
ALTGR+arecord animationAltGr+ccold reset the ST (same as the original power switch)
ALTGR+ggrab a screenshotAltGr+dopen dialog to select/change disk A
ALTGR+iboss key: leave full screen mode, pause Hatari -and iconify its windowAltGr+senable/disable sound
ALTGR+jtoggle joystick emulation via cursor keys -on/off between ports 0 and 1AltGr+qquit the emulator
ALTGR+m(un-)lock the mouse into the windowAltGr+xtoggle normal speed/fast forward
ALTGR+r(warm) reset the STAltGr+yenable/disable sound recording
ALTGR+ccoldreset the ST (same as the original power -switch)AltGr+ksave memory snapshot
ALTGR+dopen dialog to select/change disk AAltGr+lload memory snapshot
ALTGR+senable/disable soundAltGr+jtoggle joystick emulation via cursor keys + on/off between ports 0 and 1
ALTGR+qquit the emulatorAltGr+F1switch joystick type on joy port 0
ALTGR+xtoggle normal speed/fast forwardAltGr+F2switch joystick type on joy port 1
ALTGR+yenable/disable sound recordingAltGr+F3switch joystick type for joypad A
ALTGR+ksave memory snapshotAltGr+F4switch joystick type for joypad B
ALTGR+lload memory snapshotAltGr+btoggle borders on/off
ALTGR+f or F11toggle between fullscreen and windowed modeAltGr+f or F11toggle between fullscreen and windowed mode
ALTGR+o or F12activate the options GUIAltGr+o or F12activate the options GUI
PAUSEpause emulationPausepause emulation
AltGr+PAUSEinvoke the internal Hatari debuggerAltGr+Pauseinvoke the internal Hatari debugger

You can change the key bindings from the Hatari configuration file. -The required key values can be seen in the SDL_keysym.h include file -(usually in /usr/include/SDL/).

+See keymap-sample.txt file for instructions.

-

Emulated Atari ST keyboard

+

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:

- - + +
+ - - + + + + - - + + - - + + - - + + - - + + - - + + - - + +
KeyMeaningKeyMeaning
Altwill act as the ST's ALTERNATE keyAltwill act as the ST's ALTERNATE key
left CTRLwill act as the ST's CONTROL keyleft CTRLwill act as the ST's CONTROL key
Print Screenwill emulate the ST's HELP keyPrint Screenwill emulate the ST's HELP key
Scroll Lockwill emulate the ST's UNDO keyScroll Lockwill emulate the ST's UNDO key
Page Upwill emulate the ST's ( key in the keypadPage Upwill emulate the ST's ( key in the keypad
Page Downwill emulate the ST's ) in the keypadPage Downwill emulate the ST's ) in the keypad
@@ -2442,35 +1803,40 @@ are used for the directions and -

NOTE: Problems with simultenous keypresses most likely aren't an +

NOTE: Problems with simultaneous 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 +simultaneous key presses (or even just two depending on which keys are in question). Expensive gaming keyboards support more.

-

Emulated mouse

+

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 +

However it is a little bit different in windowed mode as +mouse cursor positions between host and emulated Atari can get +out of sync. This can be worked around by constraining the mouse +to the Hatari window. Pressing the AltGr+m hotkey combination or starting Hatari with the ---grab command line option. +--grab command line option +grabs the mouse i.e. locks its movements to the Hatari window. Press the shortcut key (again) to go back to normal mouse behaviour -which allows you to move mouse outside outside the Hatari window while +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

+

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 @@ -2489,7 +1855,7 @@ cursorkeys in this mode as long as you p along with the cursorkeys. You can also configure these keys from the joystick options.

-

Emulated video

+

Emulated video

Hatari emulates all screen modes of the original machine.

@@ -2506,11 +1872,11 @@ into your Mega ST.

Make sure to disable extended VDI modes for playing games as 99% of all ST games will not be able to make use of higher resolutions.

-

Emulated printer

+

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.

+

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 @@ -2520,13 +1886,13 @@ in a messy data dump in the printer outp do not format the output for a specific printer. The file contents can be used with your favourite text editor for further processing and printing to a real printer.

-

To get real direct printing out of Hatari on a PostScript printer, -you may set up a GDOS printer with a PostScript driver on the emulated -Atari and set your printer device file as Hatari's printer output.
-NOTE: This has not been tested yet and the Hatari team cannot -guarantee that it will work.

+

To get real direct printing out of Hatari you may set up a suitable +(e.g. PostScript) GDOS or NVDI printer driver on the emulated Atari and +set your printer device file as Hatari's printer output.
+NOTE: If the driver doesn't match or there's some other problem, +this can cause your printer to print out hundreds of pages of garbage.

-

Emulated RS232

+

Emulated RS232

Serial communications in Hatari is designed to directly use a serial port on your PC.

@@ -2536,13 +1902,35 @@ the communication parameters like baudra software. Hatari will do the rest and handle the serial input and output for you.

-

Floppy disk images

+

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 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 @@ -2557,7 +1945,7 @@ or doesn't use a MSDOS compatible file system, this might fail. So be very careful if you are not sure about the disk format.

The other possibility is to image the disk on a real Atari ST. -There +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 @@ -2568,8 +1956,15 @@ Hatari-incompatible disk images. However 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 @@ -2607,82 +2002,134 @@ your highscores and savegames are lost i a zipped disk image.

-

Hard disk support

+

Hard disk support

-Hatari supports three ways of emulating Atari hard drives: The low-level -ACSI and IDE hard disk emulation and a GEMDOS based drive emulation. -In most cases the GEMDOS based hard disk emulation is best as it allows +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 disk +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. How large partition sizes -are supported inside the hard disk (images) depends on the TOS version. -TOS 1.0x supports up to 256MB partitions and TOS 4.0x up to 1GB ones. +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 disk emulation

+

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. +

-With the GEMDOS based drive emulation, you can easily "mount" a -folder from the host file system to a drive of the emulated Atari. To -use the GEMDOS based drive emulation, you should use a folder on your -hard disk that only contains files and folders with valid TOS -filenames i.e. file and folders names shouldn't contain invalid GEMDOS -filename characters and their length shouldn't exceed the 8+3 file name -length limit. +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/
+

-If you provide --harddisk option -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. +That is given to Hatari as "hatari -d partitions", will give you +GEMDOS HD emulated C: and D: drives.

-GEMDOS drive emulation is an easy way to share files between the +GEMDOS HD 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 +limitations which are due to the way GEMDOS HD emulation is implemented:

-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! +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 hard disk emulation

+ +

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 disk emulation, you need a hard disk image file +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 @@ -2703,13 +2150,19 @@ the hard disk image from the emulated At 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 disk emulation

+

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 formatting IDE disks with AHDI, but you can do it with +currently support partitioning IDE disks with AHDI, but you can do it with Cecile.

@@ -2735,9 +2188,9 @@ If you only want to use your HD image in 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 AHDI 6 driver on it -instead (see ASCI hard disk -emulation section). +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 @@ -2745,62 +2198,66 @@ with the --ide

-

Moving files -to/from hard disk images

+

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 +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'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.

+

If it's 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

+

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). +Driver works fine with both the Hatari GEMDOS HD partitions and normal +hard disk images.

-

First copy the HDDRIVER.PRG binary into your GEMDOS drive emulation +

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 directory, for example like this: -"hatari --harddisk gemdos-hd/ --ide-master +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 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:.

+

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 partitions to be from D: forward, +

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 --harddisk gemdos-hd/ hd-driver-floppy.st". -

+--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

+

Accessing HDD image partitions outside of Hatari

-If you want to access the harddisk image partitions also outside +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. @@ -2810,14 +2267,12 @@ Inside the Hatari emulator, EmuTOS can a 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.

-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 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 @@ -2871,50 +2326,80 @@ from the loop device on top of the "hd"

After you've copied the relevant files to the "hd" directory, you need -unmount the file system and remove the loop device binding before using -the disk image from Hatari: +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

+ +

The debugger

Hatari has a built-in debugging interface which can be used for -analyzing code that runs in the emulated system. To invoke the -debugger, press the AltGr + Pause -key combination. +analyzing code that runs in the emulated system.

-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. +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 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).

-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 does it -with something like this (replace "xterm" with your favorite terminal -program): +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's 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.

-
-xterm -T "Hatari debug window" -e hatari
-
-

General debugger use

+

General debugger use

At the debugger prompt, type "help" to get a list of all @@ -2925,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: @@ -2945,8 +2433,10 @@ CPU commands: memdump ( m) : dump memory memwrite ( w) : write bytes to memory loadbin ( l) : load a file into memory - savebin ( s) : save memory to a file + savebin ( ) : save memory to a file symbols ( ) : load CPU symbols & their addresses + step ( s) : single-step CPU + next ( n) : step CPU through subroutine calls / to given instruction type cont ( c) : continue emulation / CPU single-stepping DSP commands: @@ -2957,11 +2447,13 @@ DSP commands: 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

+ +

Entering arguments to debugger commands

After writing (with TAB completion) one of the above command names, @@ -2998,7 +2490,7 @@ D0 register values to a command, use "a0

Within arithmetic expressions parenthesis are used both to change -the order of precendence and to indicate indirect addressing. +the order of precedence and to indicate indirect addressing. Unlike with conditional breakpoint expressions (explained below), you cannot give size for the indirect addressing, a long value is always read from the RAM address given within parenthesis. For example to @@ -3008,7 +2500,7 @@ get a long value pointed by stack pointe

Values of arithmetic expressions are always evaluated before being given to a command. Except for "evaluate" and "address" commands, -they always need to be marked with quotes (""). Besides arithmetics, +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 @@ -3016,13 +2508,13 @@ and it will be "evaluated" before being

-With command argument completion (see build +With command argument completion (see build notes), result from the last "evaluate" command can be inserted by typing '$' and pressing TAB.

-

Inspecting emulation state

+

Inspecting emulation state

In the beginning, probably the most interesting commands are "m" and "d" @@ -3056,7 +2548,12 @@ Both commands accept in addition to nume and symbol names, like in above example. If you don't specify an address, the commands continue showing from an address that comes after the previously shown data. "disasm" command default address -will be reseted to PC address everytime you re-enter the debugger. +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.

@@ -3096,18 +2593,105 @@ Without arguments "lock" command will sh

-

Debug symbols

+

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 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"). +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").

-

The symbols file format is following:

+ +

For a program under GEMDOS HD emulation

+ +

+If currently running program contains symbol table in DRI/GST format, +and it's 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" option for local symbols, both for linking
+
GCC:
+
"-Wl,--traditional-format" option for linking, + and "-g" for compilation to get local symbols
+
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 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 DRI/GST format +symbol table, or its symbols are in some other format, and you +cannot re-compile it to have them, you have two options: +

+ + +

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
@@ -3121,28 +2705,23 @@ 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 a fixed address (like e.g. EmuTOS is), after the program has been
-loaded, load the symbols with the program text segment address offset:
+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 calc.sym "TEXT"
+symbols program.sym TEXT DATA BSS
 

 

-(The value of the above virtual "TEXT" debugger variable comes from a
-program basepage, it's set after the program is loaded by TOS, see
-"info basepage" output.)
+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

+
Breakpoints

 
 

 There are two ways to specify breakpoints for Hatari. First, there are
@@ -3194,7 +2773,7 @@ conditions need to be true for a breakpo
 

 
 
-
Breakpoint options

+
Breakpoint options

 
 

 Normally when a breakpoint is triggered, emulation is stopped and you
@@ -3236,7 +2815,7 @@ changes (explained below).
 

 Show the same information on breakpoint hit as you see when entering
 the debugger (see the "lock" command in
-Inspecting emulation state
+Inspecting emulation state
 above).  This enables also trace option as you would anyway see this
 information if debugger would be entered.
 

@@ -3247,10 +2826,21 @@ Execute debugger commands from given <
 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)
+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.
+

 
 
 

@@ -3260,7 +2850,7 @@ for address breakpoints you can give onl
 

 
 
-
Breakpoint conditions

+
Breakpoint conditions

 
 

 "b help" explains very briefly the breakpoint condition syntax:
@@ -3291,7 +2881,7 @@ If the value is in parenthesis like in '
 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
+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
@@ -3304,9 +2894,9 @@ 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 coresponding value, like this:
+mask the corresponding value, like this:
 
-b ($ff820).w & 3 = (a0)  &&  (a1) = d0 & %1100
+b ($ff820).w & 3 = (a0)  &&  (a1) = d0 & %1100
 

 
 

@@ -3317,6 +2907,9 @@ which indicates inequality ("is not") co
 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's always either true or @@ -3342,17 +2935,50 @@ like this: b ($ffff9202).w ! ($ffff9202).w :trace

-Typically with this one would use the breakpoint "trace" option like -above. +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 variables

+
Breakpoint condition notes
+ + + + +

Breakpoint variables

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:

Hint: "info" command "aes", "bios", "gemdos", "vdi" and "xbios" -subcommands for can be used to list the corresponding OS-call opcodes. +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

+

Chaining breakpoints and other actions

As the file pointed by the breakpoint ":file" option (see -Breakpoint options) can contain any +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. @@ -3419,13 +3044,19 @@ another one is set.

-If tracing isn't possible for the things you'd like to track, you can -use the OS call opcode breakpoints explained above with the ":trace" -breakpoint option. +If there isn't a trace option for something you'd 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

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. +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):

@@ -3546,78 +3227,702 @@ And profiling will start once you contin 
 > c
 Returning to emulation...
-Allocated CPU profile buffer (18 MB).
+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 the RAM the execution -happened is shown: +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 (4 KB).
-Normal RAM (0-0x400000):
-- no activity
-Cartridge ROM (0xFA0000-0xFC0000):
-- no activity
+Allocated CPU profile address buffer (57 KB).
 ROM TOS (0xE00000-0xE80000):
 - active address range:
-  0xe0014c-0xe23f02
+  0xe00030-0xe611a4
 - active instruction addresses:
-  707 (100.00% of all)
+  14240 (100.00% of all)
 - executed instructions:
-  629144 (100.00% of all)
+  4589668 (100.00% of all)
 - used cycles:
-  9408503 (100.00% of all)
-- address with most cycles:
-  0xe0dcca, 402628 cycles (4.28% of all in area)
-- address with most hits:
-  0xe004a4, 4900 hits (0.78% of all in area)
+  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

+

-After this you can request more detailed profiling information: +When you're back in debugger, you can inspect the collected profile data: 

-> profile
+> h profile
 'profile' - profile CPU code
-Usage:  profile <on|off|counts|cycles|symbols|stats> [show count]
-	on & off enable and disable profiling.  Data is collected
-	until debugger is entered again after which you can view
-	statistics about the data or view PC addresses that took
-	most cycles or functions/symbols called most often.
-	You can specify how many items are shown at most.
+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:

+

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:
-0xe004a4        0.78%   4900
-0xe004b6        0.78%   4896
-0xe0dcbc        0.55%   3448
-0xe0dcc6        0.55%   3448
-0xe0f59e        0.55%   3446
-0xe0dcce        0.55%   3445
-0xe0dcd6        0.55%   3445
+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.
+

-If you have loaded symbol information for code addresses, with the -"profile symbols" command you get a list of how many times the code -execution passed through the defined symbol 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:

+ + + +

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
+...
+
+

-After the profiling information has been post-processed, it will -also be shown in the disassembly output. +For example, if you don't know all the places from which a certain +function is called, or in what context a certain interrupt handler can +be called during the period you're profiling, profile caller +information will tell you:

+
+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:

+ + + +

Saving profile data to a file

+ +

It's 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've saved from earlier versions of your code.

+ +

You may even create your own post-processing tools for +investigating the profiling data more closely, e.g. to +find +CPU/DSP communication bottlenecks.

+ + +

Profile data post-processing

+ +

Saved profile data can be post-processed with (Python) script +installed by Hatari, to:

+ + + +

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 in DRI/GST format, first they +need to be extracted to the ASCII format +understood by the post-processor:

+
+$ gst2ascii -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 -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:

+ + +

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's useful to compare both subroutine and between-symbols +costs. One should be able to see from the profile disassembly which +of the above cases is cause for the discrepancy in the values.

+

NOTE: Before starting to do any serious source +level optimizations, you should always verify from profile +data (disassembly) where exactly the costs are in a function, to make +sure your optimization efforts can actually help the performance.

-

Usage examples

+ +

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:

+ + +

Produced callgraph will look like this:

+
+ + Part of callgraph + +
+ +

Interpreting the callgraph:

+ + + +

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 it's unreadable.

+ +

If your code has interrupt handlers, they can get called +at any point, which can show in callgraph as "explicit" calls +from the interrupted functions. To get rid of such incorrect +calls, give interrupt handler names to --ignore-to option:

+
+$ 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're not interested in from how many different addresses +a given function calls another function, use --compact option. If you +still see multiple calls between two nodes with it, the reason is that +they happened through different call paths which were removed from +the callgraph after --compact option was applied:

+
+$ 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're specially interested +about, you can either color them differently with the --mark option, +or exclude everything else from the callgraph except those nodes and +their immediate callers & callees, with the --only option:

+
+$ 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
+
+
+ Kcachegrind screenshot +
+ + +

Usage examples

Here's a list of some common debugging tasks and how to do them @@ -3626,13 +3931,13 @@ with the Hatari debugger:

Stopping on program startup and examining its data
-
Please see Breakpoint variables -and Inspecting emulation state +
Please see Breakpoint variables +and Inspecting emulation state sections.
Tracing specific things in the system
-
To trace e.g. all GEMDOS calls and IO operations, use: +
To trace e.g. all GEMDOS calls and I/O operations, use: 
 trace  gemdos,io_all
@@ -3648,6 +3953,24 @@ a $12345 :6
+
Stopping when specific exception happens
+
Hatari's -D option doesn't invoke debugger on all exceptions and +doesn't allow invoking debugger just for specific exceptions. To +stop at specific exception, one can check when it's called. +At the start of memory is the CPU exception table for exception +handler addresses, 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). See also --debug-except option. +
+
Stopping when register has a specific value
To stop when e.g. D1 register contains value 5, set a breakpoint on: 
@@ -3672,7 +3995,7 @@ 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
-IO address $ff820a is set i.e. video frequency is 60Hz, set
+I/O address $ff820a is set i.e. video frequency is 60Hz, set
 a breakpoint on:
 
 b  ($ff820a).b & 2 = 2
@@ -3688,7 +4011,7 @@ b  ($ff820a).b & 2 ! ($ff820a).b & 2
 

 
 
Tracing all changes in specific memory location

-
To see the new values and continue without stopping, use
+
To see the new values and continue without stopping, add
 the ":trace" breakpoint option:
 
 b  ($ff820a).b & 2 ! ($ff820a).b & 2  :trace
@@ -3710,37 +4033,56 @@ 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 the instructions executed before debugger was entered,
-you need to enabled history tracking beforehand and then whenever the
-debugger is entered, you can request given number (here 16) of past
-instructions to be shown:
+
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 on
+history  cpu
 c
 [breakpoint is hit and debugger entered]
-history 16
+history  16
 

 

 
 
Getting instruction execution history for every breakpoint

 

-To see last 16 instructions whenever (a normal or tracing) breakpoint
-is hit:
+To see last 16 instructions for both CPU and DSP whenever
+(a normal or tracing) breakpoint is hit:
 
-history on
-lock history 16
+history  on
+lock  history 16
 c
 

 

 
-
Single step so that new register values are shown after each step

+
Single stepping so that new register values are shown after each step

 

 
-lock registers
-c 1
+lock  registers
+s
 [new register values]
-c 1
+s
 [new register values]
 ...
 

@@ -3760,10 +4102,23 @@ you enter debugger manually etc, write t
 
 lock  file stack.ini
 

-Please see also Chaining breakpoints
+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
+[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:
 
@@ -3772,18 +4127,46 @@ 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're 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" if using full command names) to do similar operation on +"d" (or "dsp" when using full command names) to do similar operation on the DSP.

-

Build notes

+

Build notes

Lastly, the debugger is much nicer to use with the command line @@ -3802,7 +4185,7 @@ By default it should be enabled.

-

Performance

+

Performance

Hatari performance varies between Atari programs, depending on what features Hatari needs to emulate for them. Less accurate Atari @@ -3813,7 +4196,7 @@ overhead.

have a noticeable effect on performance.

-

Improving Hatari performance

+

Improving Hatari performance

Hatari currently runs best in 16 or 32 bits per pixel color depth @@ -3822,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.

@@ -3851,16 +4234,16 @@ can be slower despite optimizations.

-

Emulation options

+

Emulation options

Emulation options have the largest impact on performance. These options can be changed from the Hatari GUI System dialog and the emulation needs to be rebooted for any of these changes to take -an effect! +an effect! They're enabled by default.

-
DSP
+

DSP

Emulating the Falcon DSP is performance-wise several times more demanding than emulating the m68k; DSP runs at higher frequency, executes many @@ -3871,7 +4254,7 @@ that do use DSP, many use it only for ba fine without the real DSP emulation.

-
Timer-D
+

Timer-D

The single largest factor contributing to general Hatari emulation performance is the handling of interrupts. Enabling Timer-D patching @@ -3880,7 +4263,15 @@ significantly reduces the number of inte Atari machine. Using this has adverse effect only for very rare programs.

-
Compatible CPU
+

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. +

+ +

Compatible CPU

After the DSP and interrupts, m68k emulation takes most time. Disabling the "Slower but more compatible CPU" option will speed up @@ -3899,15 +4290,15 @@ machine.

-NOTE: Above options may cause some programs not to work correctly. +NOTE: Above options may cause some programs to work in correctly. The Hatari Software Compatibility List -lists programs known to need real real Falcon DSP emulation or Timer-D -frequency. Disabling "Compatible CPU" option is recommended only as -a last resort. +lists programs known to need real Falcon DSP emulation, Timer-D +frequency or accurate FDC timings. Disabling "Compatible CPU" option +is recommended only as a last resort.

-

Emulator options

+

Emulator options

Emulator options don't usually have as large effect on performance as @@ -3916,7 +4307,7 @@ just the quality of the emulation "outpu be toggled at run-time without rebooting the emulation.

-
Sound
+

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 @@ -3927,7 +4318,7 @@ in Hatari as this can significantly redu interrupts.

-
Frame skipping
+

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 @@ -3939,12 +4330,12 @@ 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
+

Zooming

If you are not using frame skip, disabling zooming can have noticeable improvement on performance. You can do this by specifying @@ -3955,7 +4346,7 @@ mode-lines (e.g. "320x200") to your xorg to use zooming, disabling borders may help a bit.

-
Spec512 color handling
+

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 @@ -3965,7 +4356,7 @@ completely by zeroing the threshold for --spec512 0 option.

-
Statusbar and drive LED
+

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 @@ -3973,7 +4364,7 @@ impact on performance too. Normally the

-

Measuring the performance

+

Measuring the performance

There are a couple of ways to monitor and measure Hatari performance. @@ -4021,9 +4412,9 @@ at the same time you're making the measu

-

Appendix

+

Appendix

-

Copying

+

Copying

This program is free software; you can redistribute it and/or modify @@ -4045,15 +4436,13 @@ Inc., 51 Franklin Street, Fifth Floor, B Foundation | The GNU General Public License

-

Introduction to Emulation

+

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. +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 notice. -A good emulator will run most of the software intended for the emulated -platform without trouble. +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 @@ -4077,24 +4466,11 @@ error-free using such a simple loop syst

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. +emulation of the various custom chips and hardware parts of the +emulated system, and their proper synchronization, is much trickier.

-
+
-
- - - - - - - -
Valid HTML 4.01! - June 2012 -