
Hatari TO-DO list
=================

Items below are missing emulation and general emulator features.
Failures and known issues, e.g. for specific OS versions, are
listed in the "bugs.txt".

Contents:
- Emulation improvements
- Programs known as not fully functional
- Other potential Hatari functionality improvements

If you think that you can help with one of the TO-DO list items,
please get in touch with us.


Emulation improvements
----------------------

- Improve disk image formats support:
  - Support .DIM images created with the "Get sectors: used" option
  - Support files created with GCopy, see:
    https://www.atari-forum.com/viewtopic.php?t=6090

- Finish real HD 6301 (keyboard processor of the ST) emulation.
  (Current special casing is enough for all known demos using 6301)

- Allow time to be set on machines with RTC (= using host time).
  This requires calculating offset to host time on write, and
  using that offset on further reads.

- Support RTC timer interrupts needed by ASV (Atari System-V Unix):
  https://www.atari-forum.com/viewtopic.php?p=425726#p425726

- Get the games/demos working that are marked as non-working in the manual.

- Emulate different memory access timings on different memory areas.

- Improve PSG accesses timings from elsewhere than ST-RAM (HW timings
  and testier are in "PSG_WaitState() inaccuracy" mail thread).

- Improve STE / Crossbar DMA data handling.  Mask addresses similarly to
  HW (instead of modulo ST-RAM size), and generate errors when needed

- Improve TT and/or Falcon emulation, especially VIDEL:
  - Palette switching during screen drawing
  - Long writes to (word sized) color registers, see bugs.txt
  - Real Videl render offset and vertical frequency counters emulation
    (currently they're incremented so that programs checking them
    don't get stuck, but values aren't quite correct yet)
  - Video timings for the Falcon Videl chip (60Hz support):
    https://hatari.frama.io/archive/mailing-lists/tuxfamily-devel/2016/07/msg00013.html
  - ST screen modes centering when Videl borders are enabled
  - Some demos (like Yepyha) use odd (e.g. 384x1) Videl resolutions
    for transitions between screens. Size of Hatari window shouldn't
    change, screen borders should just expand to fill rest of the space
    like happens on real monitors (currently Hatari aspect corrects
    the screen height, but doesn't maintain same size)
    - This requires something specifying what the maintained Hatari
      window Falcon resolution should be

- Improve experimental SCSI hard disk emulation for Falcon/TT mode.

- Last DSP emulation / Falcon sound matrix items:
	- Dsp SSI internal clock (is it used on falcon ?)
	- Verify DSP instructions cycle count, especially with external RAM
	- Emulation of global sound reset (,expand/extend) and mute bits in
	  $ff8937 & $ff8938 registers used by TOS4
	  ("Questions on Falcon DMA sound" mail thread)

- FPU 80-bit precision mode (selected with FPUCW instruction, and
  extra instructions on 040), if there are programs depending on it.
  UAE core implements only support for 64-bit precision.  See "m68k
  FPU precision issue" thread on debian-68k mailing list for details.

- Beam Racing Algorithm for lagless VSYNC ON.  WinUAE implements it
  with DirectX:
	https://github.com/tonioni/WinUAE/issues/133

- Properly emulate the DMA sector count register for ACSI transfers
  https://hatari.frama.io/archive/mailing-lists/tuxfamily-devel/2021/09/msg00006.html


Programs known as not fully functional (not an exhaustive list)
---------------------------------------------------------------

Demos :
  - video : Omega - Full Overscan Screen, Phalanx Demo - Dragon,
	Dragonnels - Happy Island, Phaleon Demo - Future Minds,
	Decade Demo - Reset, TNT - Death Of The Left Border,
	Anomaly Demo - Menu, Delirious Demo IV - STE Detection,
	Ventura - Ultimate Dist, Syntax Terror - TCB, ICE - Kryos,
	ICE - Intruding, ICE - Jamcols, Extreme Rage, Paradox - XMas 2004,
	ICE - Space Tale, ICE - The Wave Of The Future, Snork - DNT Screen 1

Games :
  - ikbd : Superior 109 - Special Forces

For more information, see "compatibility.html".


Other potential Hatari functionality improvements
-------------------------------------------------

- Always build Hatari with raw MIDI device access, and make PortMidi
  support run-time configurable because while it's easier to use, it
  supports only MIDI events i.e. prevents using MIDI for networking in
  games (e.g. MidiMaze), and for debug output

- Improve (64e4e6d59) fix for IDE crash (and similar issues) when machine
  type is changed. Maybe call Change_CopyChangedParamsToConfiguration()
  from TOS_CheckSysConfig()?

- Copying AES/VDI vectors state at AES/VDI call so that it can be
  reliably shown with "info aes/vdi" command afterwards

- dspmemwrite, dsploadbin & dspsavebin debugger commands similar to
  their CPU variants

- Finish support for reproducible builds.  Use SOURCE_DATE_EPOCH spec
  raken either from date or last git commit (git log -1 --pretty=%ct),
  unless user overrides it.  Convert this seconds value at runtime to
  to user readable string when it's output to user.
  - timestamp handling spec:
    https://reproducible-builds.org/specs/source-date-epoch/#idm53
  - example for CMake:
    https://reproducible-builds.org/docs/source-date-epoch/#cmake
  - kernel docs + example:
    https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mkcompile_h#n26

- Better keymap table format e.g. for French
  ("Suggestion for enhanced keymap table format" mail thread)

- Improved boot drive & partition handling code:
  - count partitions the same way in ACSI, IDE & GEMDOS
  - move BootDrive stuff from floppy.c e.g. to tos.c where NumDrives is

- Support harddisk write protection also for IDE & ACSI drives?

- Fix GST symbol table detection in debugger & gst2ascii.  Currently
  it will just process whatever it thinks the symbol table to
  contain (which output can mess the console).  MiNT binaries can
  contain GST symbol tables, so checking that isn't enough.

- Preliminary debugger work for the other features + cleanup:
	- Skip & tell user to rename any of the loaded symbols that
	  have same name as internal Hatari variables
	- Change "" for expressions to {} so that quotes can
	  be used for e.g. search strings?

- While Hatari debugger has many features that Steem one doesn't have,
  that also has debugging features missing from the Hatari debugger.

  These ones should be straightforward to implement:
	- Breakpoints on interrupts
	- Showing values both in different lengths and numeric bases.
	  (In Hatari one gets latter with "evaluate" command, e.g. "e a0",
	  and showing the value as long/word/byte requires ANDing it)
	- All register values being shown with above info
          (= Steem Register monitor)
	- info commands for PSG and FDC register values
	  (= Steem monitors for these)
	- Info command for "timings" i.e. cycles since HBL/VBL,
	  timer values, video address & scanline
	  (= Steem Timings view)
	- memory dump with just text format
	  (= Steem Text monitor)
        - Stack content display: m "a7-$40"-"a7"
	  (= Steem Stack display)
	- Run for N cycles
	  (Hatari 'continue' command accepts only instructions, not cycles)

  These are more complicated ones:
	- Monitoring reads & writes to specific address.  Hatari supports
	  only tracing changes to values, not having breakpoints on
	  reading values or writing the same value.  Slow
	  (this is most requested debugger feature)
	- Showing breakpoints in instruction dumps.  Hatari breakpoints
	  are more advanced than the trivial address breakpoints, so
	  this would require adding support also for plain PC based
	  breakpoints (currently 'address' command is translated to
	  a conditional breakpoint)
	- Adding new symbol names for arbitrary addresses one at the time.
	  Hatari debugger currently requires new symbols to be added to
	  a file containing all the symbols + reloading that file
	- Memory dump that shows also disassembly and values
	  in different bases
	  (= Steem Memory monitor)

  Basic GUI debugger features:
	- Ability to open as many dump/info windows as wanted
	  (hex/asm/mfp/video/sound/...) and have their content
	  refreshed each time emulation is stopped.
	- A stop/run button and a debugger "step" button
	- Possibility to click to an address on dump window to define
	  a simple PC breakpoint (or monitor memory on B/W/L accesses)

(See "Steem debugger features not in Hatari debugger"
on BerliOS hatari-devel mail thread for more info.)

- MonST debugger features missing from Hatari debugger
  (ones not already mentioned in Steem feature list):
	- Address breakpoints can have conditions that are evaluated
	  only on that address
	- Marking breakpoint types in disassembly (<count> for counted
	  ones, ? for conditional ones, * for others)
	- Shortcut command for telling to run until given
	  (temporary) conditional breakpoint is hit
	- Running until code returns from ROM (exiting from super mode?)
	- Single stepping that skips Traps, Line-A, Line-F. And one that
	  skips also BSRs and JSRs
	  ('next' command runs until instruction of given type)
	- Saving full machine status (like registers) to history buffer
	  each time debugger is entered (exception or breakpoint is hit)
	  and viewing of that history
	- SP & SSP as CPU register names (active & supervisor stack)
	- Fill and copy memory command
	- Search for an address which disassembly output matches
	  given instruction substring

- Improved screen handling:
	- Line based screen change detection/checks:
		- blit only changed lines
		- simpler / faster (LED) overlay handling
	- Include some fancy zooming routines like 2xSaI or Super-Eagle

- Add Hatari "fileid" to more files (to ease locating "stolen" code)
  and Git hook to remove trailing whitespace (sed -i 's/[\t ]*$//')?
