
Hatari bugs
===========

Below are listed known failures with Hatari.

Contents:
- Related documents
- Emulator bugs
- Known issues with workarounds
- External bug reports


Related documents
-----------------

Missing features are listed in the "todo.txt" file.

Emulation option compatibility issues with specific games and demos
are documented in the "compatibility.html" file.

Additional emulation issues specific to running Linux kernel are
listed in the "m68k-linux.txt" file.

Compatibility issues with EmuTOS (TOS version distributed with Hatari
binaries), are documented in the "emutos.txt" file.  They're related
to missing EmuTOS functionality and byte-exactness with old TOS
versions, not to Hatari.


Emulator bugs
-------------

* RS232 support on Mac / BSD:

  - Threaded RS232 code is completely broken for BSD derived systems
    like Mac, because they don't implement fine-grained FILE operation
    locking like Linux/Glibc does (and Windows?). As a result,
    re-configuring, or closing RS232 files, will cause deadlock with
    the reading thread

  - With SDL1, close deadlock could be handled by killing the read
    thread before closing file handles, but SDL2 removed that
    functionality. As a result, enabling RS232 will freeze SDL2 Hatari
    version on exit on BSD / Mac, even if RS232 was unused

  - Solving this would require rewriting the code with OS specific
    primitives (instead of using SDL), either for threading, or using
    select().  I'd prefer latter, for clarify and to avoid polling in
    the main thead, but it would mean that RS232 won't work on Windows
    until somebody contributes code for that too

* MIDI support on Mac / Windows:

  - MIDI support on these platforms requires Hatari to be built with
    PortMidi library, and PortMidi requires additional Hatari code to
    translate MIDI port data from/to PortMidi MIDI events. However,
    that translation doesn't work 100% correctly yet

    For example, PortMidi complains about invalid MIDI event data at
    startup (MIDI setup?) of "Sequencer One" and "Fractal Music"
    programs, loading of every song (MIDI setup / sysex?) in "Cubase
    Lite", or starting song in "Dr. T's KCS" (v4.0) and "GenEdit"
    (v2.02), after which PortMidi connection gets closed and nothing
    else will go through. And if MIDI events would still be let
    through, they would then use wrong instruments

    (PortMidi is missing documentation that would help in resolving
    whether this is Hatari or PortMidi bug.)


Known issues / workarounds
--------------------------

* Printing doesn't work in auto-started programs with TOS v1.02 - v2.06:

    Why: program startup is so fast that TOS hasn't had time to start
    200hz tick used for printing.

    WA: put tests/autostart/4_secs.prg to AUTO/-folder to slow down
    program startup enough for printing to work


External bug reports
--------------------

* Problem: On real Falcon there is a minor feature in videl. You can simply
  fade whole screen to black, if you just clear the Horizontal Border End
  ($ffff8286) and start fading colors from 0 to 255 to $ffff9800 or vice versa.
	test <put picture to screen>
	move.w #255-1,d7
	moveq #0,d6
	.loop <vsync, stop#$2300>
	clr.w $ffff8286.w
	move.l d6,$ffff9800.w
	addq.l #1,d6
	dbf d7,.loop
  Now it does this exactly opposite direction, it fades bgcolor from 0 to 255.
  http://developer.berlios.de/bugs/?func=detailbug&bug_id=18002&group_id=10436

* To compare my real Falcon with Hatari on my Windows 7 PC, I make some short
  benchmarks with Kronos. The disk benchmark in Kronos runs in 1-2 minutes on
  my real Falcon. The same disk benchmark in Kronos under Hatari 1.5 runs
  longer than 20 minutes with GEMDOS emulation.  Only when I use the AltGr + X
  option, before the benchmark runs, then the disk benchmark in kronos is
  comparable fast as my 16MHz Falcon.
  http://developer.berlios.de/bugs/?func=detailbug&bug_id=18298&group_id=10436

  -> Hatari GEMDOS emulation needs to do a lot of extra kernel file & directory
     accesses which with current code seem unavoidable.  They're a problem only
     with test programs like Kronos, for those one should consider using
     harddisk image files instead.
