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

- The "memvalid" system variables currently have to be patched in most cases.
  For improved compatibility (e.g. the game "Yolanda") it would be better to
  skip this step, but we then run into multiple other problems, see:
  http://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2011/12/msg00123.html


Programs known as not fully functionnal (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
  - cpu/timers : Pandemonium Demos - Mega 3D, Audio Art, UMD Intro
  - ikbd : Dragonnels - Unlimited Bobs

Games :
  - cpu/timers : FOF 42 - Subbuteo, Bolo, Final Conflict, The Ultimate Ride,
	Treasure Trap
  - ikbd : F29, Superior 109 - Special Forces, Warlock's Quest


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:
	- 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 interrupts
	- 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.
	- 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.


Bug reports
-----------

- When playing Tautology 2 I noticed the mod player sound goes in and out of
  sync. fading into crackle and back. (Using Hatari 1.4 with TOS 4.04 on Mac
  OS X 10.6.5)
  http://developer.berlios.de/bugs/?func=detailbug&bug_id=17781&group_id=10436

- 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 any
  longer than 20 minutes. 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
