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 ---------------------- - Add fastload program header flag support to GEMDOS HD emulation (If PF_FASTLOAD flag is set, clear just BSS, not heap) - Investigate what TOS version/functionality doesn't work for (Falcon) programs started from the DESKTOP/NEWDESK.INF and why, e.g: - Printing doesn't work with TOS versions v1.02 - v2.06 - Colors in 2-plane VDI resolution are not set correctly - "Running" game preview and shareware versions crash - Fun's "Men at War" game or its intro don't start - "Push It" game crashes if auto-started - NoCrew: Aggressive Party II 128k combo ("Whirlpool") bombs - RG: "Sworm" & "Sky Fall" games want to access A: & B: when autostarted - JAM packer packed version of Tony Benett' "Virtual City" demo bombs - Sentry 2.2 packed version of Shadows' "Firestarter" demo bombs Note: last 3 programs can be autostarted fine with EmuTOS. Document that in manual (page) for the Hatari "autorun" feature. - Related to above, investigate why TOS v1.04 crashes shortly after GEM programs started with autorun feature are exited. If programs are started from TOS v1.04 desktop, there's no crash. - Keyboard detection sometimes fails when --fast-forward is enabled while TOS boots / game is loaded (e.g. Falcon Snake game packed with Sentry). - Improve disk image formats support: - 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) - Get the games/demos working that are marked as non-working in the manual. - Improve TT and/or Falcon emulation, especially VIDEL, e.g: - Palette switching during screen drawing - Video timings for the Falcon Videl chip (60Hz support): https://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2016/07/msg00013.html - ST screen modes centering when Videl borders are enabled - Videl video register access (e.g. VIDEL_ScreenCounter_ReadByte() never changes the register value unless it had first specifically been written into): http://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2013/02/msg00155.html - Emulate border color: http://atari-forum.com/viewtopic.php?f=51&t=29098 - Add SCSI hard disk emulation for Falcon/TT mode. - ACSI emulation doesn't work with TOS v3 (but works for TT/EmuTOS). - Add SCC serial port emulation for Falcon/TT mode. - DSP emulation / Falcon sound matrix: - Dsp SSI internal clock (is it used on falcon ?) - Verify DSP instructions cycle count, especially with external RAM - 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. - 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 -> We should emulate the MMU memory bank configuration at $FF8001 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 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? - 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: - 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? - 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 - 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 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, 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) - 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 - 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 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) - A way to search for hex/text in Hatari's RAM. (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. 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: - 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 - 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... - 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 ----------- - Ishar 1, 2 & 3 and Hextracker freeze at start with Falcon emulation because Videl screen address counter doesn't advance (its read & write IO functions are no-ops, a regression from 2...
raportbobowy1234