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

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


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

- Improve FDC emulation (e.g. read-track and write-track commands do not work
  right yet).

- Improve disk image formats support:
	- Add support for .STT images
	  (created with the STEEM disk image program)
	- Add support for Pasti .STX images
	  (See http://pasti.fxatari.com/)
	- Support .DIM images created with the "Get sectors: used" option

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

- Finish upgrading the CPU core of Hatari to the latest WinUAE
  which has better cycle accuracy needed by some programs:
	- Integrate MMU emulation
	- Add Exception debugging support
	- Instead of calling Reset_Cold()/m68k_reset()/uae_reset()
	  directly from newcpu.c, show user a notice (dialog)
	  about what happened and let user do the reboot
	  (see "Emulation reset, old-UAE vs. WinAUE core" mail-thread)
	- Update WinUAE core to its latest (a year newer) version
	- Fix & document cmdline options for selecting prefetch etc
	  - GUI options for above

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

- Improve TT and/or Falcon emulation, especially VIDEL

- TT/FastRAM support as some demos need >14MB

- Add SCSI hard disk emulation for Falcon/TT mode.

- ACSI emulation seems to be broken in TT mode.

- Add SCC serial port emulation for Falcon/TT mode.

- Some Falcon games/demos only work with 32 MHz CPU emulation.
  (might be due to timings problems (videl, DMA, cpu cycles, dsp cycles, ...))

- Fix falcon sound quality (sound is sometimes noisy)
  Sound is also toggling between nice to noise with some demos.

- Improve STE Microwire/LMC1992 emulation.

- DSP emulation / Falcon sound matrix:
	- Dsp SSI internal clock (is it used on falcon ?)
	- Verify DSP instructions cycle count, especially with external RAM


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

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

- Preliminary debugger work for the other features + cleanup:
	- All DebugUI invocations should give reason for it
	  (exception, breakpoint...)
	- All parsing functions should return error code on error
	- Eval_Number() could take DSP/CPU flag like Eval_Range()
	  does so that all commands taking numeric args can accept
	  also symbol, variable & register names
	- 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?

- Steem emulator debugging features missing from Hatari debugger.
  These should be straightforward to implement:
	- Breakpoints on iterrupts
	- Breaking on exceptions 2-8 vs. bombs vs. don't break.
          Hatari has only an option to break on address & bus errors
	  & uninitialized exception handler.
	- History of executed instructions and how many cycles they took
	  (= Steem History view & Trace info)
	- Showing values both in different lengts and numeric bases.
	  (In Hatari one gets latter with "evaluate" command, e.g. "e a0",
	  but that doesn't show the value as it were long/word/byte)
	- All register values being shown with above info
          (= Steem Register monitor)
	- info commands for PSG, MFP, FDC and IKBD 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 in text format
	  (= Steem Text monitor)
        - Stack content display: m "a7-$40"-"a7"
	  (= Steem Stack display)
	- Text string and binary values (hex) search
	  (= widgets in Steem monitor windows)
	- Disasm format options being changable at run-time
	  (= Steem options)
	- 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 monitoring changes to values, not having breakpoints of
	  reading values or writing the same value.  Slow
	- Showing breakpoints in instruction dumps.  Hatari breakpoints
	  are more advanced than the trivial address breakpoints, so
	  this would require adding efficient support for plain PC
	  based breakpoints
	- 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 those 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)
	- A way to search for hex/text in Hatari's RAM.

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

- MonST debugger features missing from Hatari debugger
  (ones not mentioned in Steem features):
	- 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.  Run until RTS/RTE command
	- 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
	- User variables which values can be set & used in expressions

- Improved screen handling:
	- Direct 16-bit & 32-bit support for monochrome and VDI modes
	  (currently they're converted through 8-bit surface)
	- Line based screen change detection/checks:
		- blit only changed lines
		- simpler / faster (LED) overlay handling
	- x3 and x4 zooming routines for ST-Low resolution
	- Include some fancy zooming routines like 2xSaI or Super-Eagle
	- Add support for hardware accelerated zooming with
	  SDL YUV overlays or OpenGL

- Check/clean RS232 code:
	- polls at 2/20ms intervals and reads data byte at the time.
	  SDL_Delay()s & fgetc() could be replaced (at least on unix)
	  with select() and fread().  Or just remove the rs232 thread
	  and use an interrupt for it...
	- The commented out rs232 stuff could be removed from gemdos.c
	  (RS emulation is done at HW, not Gemdos level).

- Improve directory handling:
	- Currently screenshots & anim go always to current dir,
	  whereas memsave, sound recording, printer & midi & serial &
	  output and log output go to file specified in config file.
	  There should be support for setting also anim/screenshot
	  directory / file name from config file (needs change also
	  in screenSnapShot.c).
	- By default the directory config values should be empty in
	  which case the code will at run-time decide to use current
	  directory, but not modify the path config setting.
