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. 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 * PortMidi device disconnects: Playback of Notator 3.x "DEMO8.SON" song (which has very large amounts of sysex data) can trigger "Operation not permitted" PortMidi "host error" around 7:00 mark, resulting in MIDI output being disabled (until MIDI device is changed or Hatari restarted). This is triggered completely randomly, but seems to be issue on the receiving end as it happens only when connected to Qsynth / FluidSynth, not when using just MIDI through as output. WA: Avoid non-working MIDI data / softsynth combinations. * Mac GUI support only PortMidi devices, not raw MIDI devices: Direct file access is required to use MIDI for debugging output or networking (up to 16 machines) over MIDI. Mac users have not yet contributed a support for that to Mac GUI. WA: configure that with SDL GUI for now * Neither RS-232 nor raw MIDI device file input is supported on Windows: Input for both RS-232 and raw MIDI device files is checked with File_InputAvailable() function which uses select() POSIX functionality to do it. Windows users have not yet contributed corresponding Windows functionality to it. WA: Use Linux version of Hatari under Windows: https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps 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 move.w #255-1,d7 moveq #0,d6 .loop 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. * 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. -> 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.