[hatari-devel] Hatari 1.5 ?

[Eero Tamminen]

Hi,

On Thursday 02 September 2010, npomarede at corp.free.fr wrote:
> On Thu, 2 Sep 2010, Laurent Sallafranque wrote:
>> What is planed for hatari V 1.5 ?
>>
>> What are the main subjects to work on ?
>> - I can continue to correct some Falcon bugs
>> - I still have the 6800 emulation to complete (but that's not a
>> priority for now)
>> - I still would enjoy to have a bus cycle emulation instead of cpu
>> cycle one.

DSP tracing support to debugger?

Could you also look at this potential DSP issue:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=17464&group_id=10436
?

And maybe investigate why sound doesn't work with LLamaZap, FalcAmp, 
FlaySid, FlexTrax?


> I agree real ikbd 6802 is not a top priority
>
> and better cycle precision is still possible, but needs a lot of work to
> get in sync with winuae code.

What about MMU or Fast RAM support?

TT emulation bugs?


> But now that you've got a real falcon, maybe it could be useful to add
> better video support, such as raster / video interrupt for example.

Better Videl support would indeed be nice...


I have nowadays less time for Hatari, but I have on my todo list:

* Optionally getting Hatari fullscreen resolution from current
  display resolution

* Line based ST/STE screen change detection/checks:
  - blit only changed lines
  - simpler / faster (LED) overlay handling
  As discussed earlier.  It could speed up demos and games that do
  constant (near) fullscreen updates.  This would be pretty huge code
  change though.

* Tests directory re-organization + adding there some stuff
  that can be useful for Hatari users (for finding Atari & SDL keycodes
  for key mappings).

* Possibly some more Monst debugger features listed in the todo.txt
  if people are interested to have them.  And of course fixing any
  possible bugs in the current debugger features.

* Finishing the profiler stuff:
  - Documenting it
  - Fixing CPU&DSP cycles counting
  - Any other issues people report on it

Laurent, could you test the DSP profiler?

IMHO it's nice to get an overview of what code is executed as reading
tracing output is quite inconvenient and slows down emulation too much.


* Then there's some general code improvents:
  - count partitions the same way in ACSI, IDE & GEMDOS
  - move BootDrive stuff from floppy.c e.g. to tos.c where NumDrives is
  - allow log file changing at run-time

* Potential Python UI improvements:
  + Supporting in the debugger UI:
    - DSP
    - stepping
    - symbol loading
    - profiling
  + creating empty floppies using hmsa


	- Eero