--- hatari/doc/manual.html 2019/04/09 08:49:50 1.1.1.13 +++ hatari/doc/manual.html 2019/04/09 08:52:20 1.1.1.16 @@ -55,15 +55,15 @@

Hatari User's Manual

Index

@@ -175,7 +175,8 @@ Recent versions of Hatari even feature S

Features

-Hint: "info" command "aes", "gemdos" and "vdi" subcommands for can be -used to list the corresponding OS-call opcodes. For example, -to see the GEMDOS opcodes, use:

+Hint: "info" command "aes", "bios", "gemdos", "vdi" and "xbios" +subcommands for can be used to list the corresponding OS-call opcodes. +For example, to see the GEMDOS opcodes, use:

 info gemdos 1
 
@@ -3383,7 +3489,7 @@ debugger prompt before continuing.

Disable tracing with "trace none" when you enter the debugger again. -"trace help" (or TAB) can be used to list all the (over 30) supported +"trace help" (or TAB) can be used to list all the (over 40) supported traceable things, from HW events to OS functions.

@@ -3398,9 +3504,8 @@ which tell it to intercept this higher l (which doesn't work under MiNT because it re-implements GEMDOS)

-If use of above 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. +Unlike with AES and VDI tracing, BIOS, GEMDOS and XBIOS traces show +arguments for most of the calls.

Tracing options can be set even from a program within the emulation @@ -3413,6 +3518,11 @@ console. Note that the trace output file can be set only when Hatari starts, it cannot be changed from within the debugger (or emulation).

+

+If tracing isn't possible for the things you'd like to track, you can +use the OS call opcode breakpoints explained above with the ":trace" +breakpoint option. +

Profiling

@@ -3527,7 +3637,7 @@ sections. trace gemdos,io_all Please see Tracing section for more information -on tracing, what's possible with in and what are its limitations. +on tracing, what's possible with it and what are its limitations.
Stopping when certain PC address is passed Nth time
@@ -3600,6 +3710,30 @@ b d0 = "d0 + 10" +
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: +
+history on
+c
+[breakpoint is hit and debugger entered]
+history 16
+
+
+ +
Getting instruction execution history for every breakpoint
+
+To see last 16 instructions whenever (a normal or tracing) breakpoint +is hit: +
+history on
+lock history 16
+c
+
+
+
Single step so that new register values are shown after each step
@@ -3630,9 +3764,8 @@ Please see also 
 
 
@@ -3654,14 +3787,15 @@ DSP.
 
 

Lastly, the debugger is much nicer to use with the command line -history, editing and especially with the command, command argument and -symbol name completion support. If you're building Hatari yourself, -please make sure that you have the GNU readline development files -installed (on Debian / Ubuntu these come from the libreadline5-dev -package). Otherwise completion doesn't get enabled when you configure -Hatari. +history, editing and especially the completion support for the +command, command argument and symbol names. +

+

+If you're building Hatari yourself, please make sure that you have the +GNU readline development files installed (on Debian / Ubuntu these +come from the libreadline5-dev package). Otherwise the name completion +and other features don't get enabled when you configure Hatari.

-

ENABLE_TRACING define needs to be set for tracing to work. By default it should be enabled. @@ -3731,7 +3865,7 @@ an effect! Emulating the Falcon DSP is performance-wise several times more demanding than emulating the m68k; DSP runs at higher frequency, executes many instructions for each m68k instruction and emulation isn't as mature -and optimized. Unless some program needs DSP, none or +and optimized. Unless some Falcon program needs DSP, none or dummy DSP emulation mode could be used. Even of the programs that do use DSP, many use it only for background music and work fine without the real DSP emulation. @@ -3826,15 +3960,16 @@ to use zooming, disabling borders may he Handling Spec512 color modes which change the ST/e palette constantly takes some extra CPU. If you have problems with CPU usage in such screens and you care more e.g. from the sound quality than visuals, you -can disable the Spec512 mode handling by zeroing the threshold for that -with the --spec512 0 option. +can either increase the threshold or disable the Spec512 mode handling +completely by zeroing the threshold for that with the +--spec512 0 option.

Statusbar and drive LED

-If your version of libSDL uses VSync to synchronize the screen output, -drawing of the statusbar or the drive LED may have some minor impact -on performance too. Normally they shouldn't. +If your version of the SDL library uses VSync to synchronize the screen +output, drawing of the statusbar or the drive LED may have some minor +impact on performance too. Normally they shouldn't.

@@ -3863,13 +3998,13 @@ It depends on what you want to measure, disable sound and set high frame skip like --sound off --frameskips 60 so that the associated external overheads are minimized. E.g. video output -can on some platforms do VSync and measurements would then show -your monitor refresh frequency instead of actual Hatari performance. +can on some platforms do VSync and measurements would then show your +monitor refresh frequency instead of the actual Hatari performance.

On Unix systems with times() function call, only the time spent by the Hatari process itself is measured. -On other systems much less accurate SDL "wall clock" timings are +On other systems, much less accurate SDL "wall clock" timings are used. To make latter more accurate you could use also --run-vbls option to specify how many VBLs Hatari should run before it exits. In this case it's best to @@ -3878,7 +4013,7 @@ given as memory snapshot to Hatari with the VBL count.

-Note that the numbers can fluctuate quite a bit, especially +Note that these numbers can fluctuate quite a bit, especially when the SDL timings are used, so for (statistically) reliable numbers you may need to repeat the measurement several times. You should of course make also sure that the system doesn't have any other activity @@ -3956,7 +4091,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"> - June 2011 + June 2012