|
|
1.1 root 1:
1.1.1.4 root 2: Hatari TO-DO list
3: =================
1.1 root 4:
1.1.1.4 root 5: If you think that you can help with one of the TO-DO list items, please get
6: in touch with us.
1.1 root 7:
1.1.1.6 root 8:
1.1.1.4 root 9: Emulation improvements
10: ----------------------
1.1 root 11:
1.1.1.11 root 12: - Investigate what TOS version/functionality doesn't work for programs
13: started from the DESKTOP/NEWDESK.INF and why, e.g:
14: - Printing doesn't work with TOS versions v1.02 - v2.06
1.1.1.12! root 15: - Colors in 2-plane VDI resolution are not set correctly
1.1.1.11 root 16: - Tony Benett: Virtual City demo bombs
17: - NoCrew: Aggressive Party 2 4k demo doesn't work
18: - Running 1997 shareware version doesn't work
19: Document that in manual (page) for the Hatari "autorun" feature.
20:
21: - Keyboard detection sometimes fails when --fast-forward is enabled
22: while TOS boots / game is loaded (e.g. Falcon Snake game packed
23: with Sentry).
24:
1.1.1.3 root 25: - Improve disk image formats support:
1.1.1.6 root 26: - Add support for .STT images
27: (created with the STEEM disk image program)
28: - Add support for Pasti .STX images
29: (See http://pasti.fxatari.com/)
30: - Support .DIM images created with the "Get sectors: used" option
1.1 root 31:
1.1.1.8 root 32: - Real HD 6301 (keyboard processor of the ST) emulation.
1.1.1.4 root 33: (Current special casing is enough for all known demos using 6301)
1.1 root 34:
1.1.1.8 root 35: - Finish upgrading the CPU core of Hatari to the latest WinUAE
36: which has better cycle accuracy needed by some programs:
1.1.1.12! root 37: - Finish MMU emulation support
1.1.1.8 root 38: - Add Exception debugging support
39: - Instead of calling Reset_Cold()/m68k_reset()/uae_reset()
40: directly from newcpu.c, show user a notice (dialog)
41: about what happened and let user do the reboot
1.1.1.11 root 42: (see "Emulation reset, old-UAE vs. WinUAE core" mail-thread)
1.1.1.12! root 43: - Make WinUAE core ST/STE emulation as good as with old UAE core
1.1.1.8 root 44: - Update WinUAE core to its latest (a year newer) version
1.1.1.12! root 45: - Document cmdline options for selecting prefetch etc
! 46: once they're stable
1.1 root 47:
48: - Get the games/demos working that are marked as non-working in the manual.
49:
1.1.1.11 root 50: - Improve TT and/or Falcon emulation, especially VIDEL, e.g:
51: - Palette switching during screen drawing
52: - ST screen modes centering when Videl borders are enabled
1.1.1.12! root 53: - Videl video register access (e.g. VIDEL_ScreenCounter_ReadByte()
! 54: never changes the register value unless it had first specifically
! 55: been written into):
! 56: http://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2013/02/msg00155.html
1.1.1.4 root 57:
1.1.1.8 root 58: - TT/FastRAM support as some demos need >14MB
59:
1.1.1.5 root 60: - Add SCSI hard disk emulation for Falcon/TT mode.
1.1.1.4 root 61:
1.1.1.12! root 62: - ACSI emulation doesn't work with TOS v3 (but works for TT/EmuTOS).
1.1.1.6 root 63:
1.1.1.4 root 64: - Add SCC serial port emulation for Falcon/TT mode.
65:
1.1.1.10 root 66: - Disable VDI mode for TOS v4 as it doesn't support it (and VDI mode
67: is redundant as Falcon's Videl allows similar resolutions)
1.1.1.6 root 68:
1.1.1.11 root 69: - Fix falcon sound quality (sound is sometimes noisy).
1.1.1.8 root 70: Sound is also toggling between nice to noise with some demos.
1.1.1.6 root 71:
1.1.1.8 root 72: - DSP emulation / Falcon sound matrix:
1.1.1.7 root 73: - Dsp SSI internal clock (is it used on falcon ?)
1.1.1.8 root 74: - Verify DSP instructions cycle count, especially with external RAM
1.1.1.6 root 75:
1.1.1.12! root 76: - FPU 80-bit precision mode (selected with FPUCW instruction, and
! 77: extra instructions on 040), if there are programs depending on it.
! 78: UAE core implements only support for 64-bit precision. See "m68k
! 79: FPU precision issue" thread on debian-68k mailing list for details.
! 80:
1.1.1.9 root 81: - The "memvalid" system variables currently have to be patched in most cases.
82: For improved compatibility (e.g. the game "Yolanda") it would be better to
83: skip this step, but we then run into multiple other problems, see:
84: http://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2011/12/msg00123.html
85:
86:
1.1.1.10 root 87: Programs known as not fully functional (not an exhaustive list)
88: ---------------------------------------------------------------
1.1.1.9 root 89:
90: Demos :
91: - video : Omega - Full Overscan Screen, Phalanx Demo - Dragon,
92: Dragonnels - Happy Island, Phaleon Demo - Future Minds,
93: Decade Demo - Reset, TNT - Death Of The Left Border,
94: Anomaly Demo - Menu, Delirious Demo IV - STE Detection,
95: Ventura - Ultimate Dist, Syntax Terror - TCB, ICE - Kryos,
96: ICE - Intruding, ICE - Jamcols, Extreme Rage, Paradox - XMas 2004,
97: ICE - Space Tale, ICE - The Wave Of The Future, Snork - DNT Screen 1
1.1.1.12! root 98: - cpu/timers : UMD Intro
1.1.1.9 root 99:
100: Games :
1.1.1.12! root 101: - cpu/timers : FOF 42 - Subbuteo, The Ultimate Ride, Treasure Trap
! 102: - ikbd : Superior 109 - Special Forces
1.1.1.9 root 103:
1.1.1.6 root 104:
105: Other potential Hatari functionality improvements
106: -------------------------------------------------
107:
1.1.1.7 root 108: - Improved boot drive & partition handling code:
109: - count partitions the same way in ACSI, IDE & GEMDOS
110: - move BootDrive stuff from floppy.c e.g. to tos.c where NumDrives is
111:
112: - Support harddisk write protection also for IDE & ACSI drives?
113:
1.1.1.12! root 114: - Fix GST symbol table detection in debugger & gst2ascii. Currently
! 115: it will just process whatever it thinks the symbol table to
! 116: contain (which output can mess the console). MiNT binaries can
! 117: contain GST symbol tables, so checking that isn't enough.
! 118:
1.1.1.8 root 119: - Preliminary debugger work for the other features + cleanup:
120: - Eval_Number() could take DSP/CPU flag like Eval_Range()
121: does so that all commands taking numeric args can accept
122: also symbol, variable & register names
123: - Skip & tell user to rename any of the loaded symbols that
124: have same name as internal Hatari variables
1.1.1.9 root 125: - Change "" for expressions to {} so that quotes can
1.1.1.8 root 126: be used for e.g. search strings?
127:
1.1.1.11 root 128: - While Hatari debugger has many features that Steem one doesn't have,
129: that also has debugging features missing from the Hatari debugger.
130:
131: These ones should be straightforward to implement:
1.1.1.9 root 132: - Breakpoints on interrupts
1.1.1.8 root 133: - Breaking on exceptions 2-8 vs. bombs vs. don't break.
134: Hatari has only an option to break on address & bus errors
135: & uninitialized exception handler.
1.1.1.12! root 136: - Showing values both in different lengths and numeric bases.
1.1.1.8 root 137: (In Hatari one gets latter with "evaluate" command, e.g. "e a0",
1.1.1.12! root 138: and showing the value as long/word/byte requires ANDing it)
1.1.1.8 root 139: - All register values being shown with above info
140: (= Steem Register monitor)
141: - info commands for PSG, MFP, FDC and IKBD register values
142: (= Steem monitors for these)
1.1.1.11 root 143: - Info command for "timings" i.e. cycles since HBL/VBL,
1.1.1.8 root 144: timer values, video address & scanline
145: (= Steem Timings view)
146: - memory dump in text format
147: (= Steem Text monitor)
148: - Stack content display: m "a7-$40"-"a7"
149: (= Steem Stack display)
150: - Text string and binary values (hex) search
151: (= widgets in Steem monitor windows)
152: - Run for N cycles
1.1.1.11 root 153: (Hatari 'continue' command accepts only instructions, not cycles)
154:
1.1.1.8 root 155: These are more complicated ones:
156: - Monitoring reads & writes to specific address. Hatari supports
1.1.1.11 root 157: only tracing changes to values, not having breakpoints of
1.1.1.8 root 158: reading values or writing the same value. Slow
159: - Showing breakpoints in instruction dumps. Hatari breakpoints
160: are more advanced than the trivial address breakpoints, so
161: this would require adding efficient support for plain PC
162: based breakpoints
163: - Adding new symbol names for arbitrary addresses one at the time.
164: Hatari debugger currently requires new symbols to be added to
165: a file containing all the symbols + reloading that file
166: - Memory dump that shows also disassembly and values
167: in different bases
168: (= Steem Memory monitor)
1.1.1.11 root 169:
1.1.1.8 root 170: Basic GUI debugger features:
171: - Ability to open as many dump/info windows as wanted
1.1.1.11 root 172: (hex/asm/mfp/video/sound/...) and have their content
1.1.1.8 root 173: refreshed each time emulation is stopped.
174: - A stop/run button and a debugger "step" button
175: - Possibility to click to an address on dump window to define
176: a simple PC breakpoint (or monitor memory on B/W/L accesses)
177: - A way to search for hex/text in Hatari's RAM.
178:
179: (See "Steem debugger features not in Hatari debugger"
1.1.1.11 root 180: on BerliOS hatari-devel mail thread for more info.)
1.1.1.8 root 181:
182: - MonST debugger features missing from Hatari debugger
183: (ones not mentioned in Steem features):
184: - Address breakpoints can have conditions that are evaluated
185: only on that address
186: - Marking breakpoint types in disassembly (<count> for counted
187: ones, ? for conditional ones, * for others)
1.1.1.7 root 188: - Shortcut command for telling to run until given
189: (temporary) conditional breakpoint is hit
190: - Running until code returns from ROM (exiting from super mode?)
191: - Single stepping that skips Traps, Line-A, Line-F. And one that
1.1.1.8 root 192: skips also BSRs and JSRs. Run until RTS/RTE command
193: - Saving full machine status (like registers) to history buffer
194: each time debugger is entered (exception or breakpoint is hit)
195: and viewing of that history
1.1.1.7 root 196: - SP & SSP as CPU register names (active & supervisor stack)
197: - Fill and copy memory command
1.1.1.8 root 198: - Search for an address which disassembly output matches
199: given instruction substring
200: - User variables which values can be set & used in expressions
1.1.1.6 root 201:
202: - Improved screen handling:
203: - Direct 16-bit & 32-bit support for monochrome and VDI modes
204: (currently they're converted through 8-bit surface)
205: - Line based screen change detection/checks:
206: - blit only changed lines
207: - simpler / faster (LED) overlay handling
208: - x3 and x4 zooming routines for ST-Low resolution
209: - Include some fancy zooming routines like 2xSaI or Super-Eagle
210: - Add support for hardware accelerated zooming with
211: SDL YUV overlays or OpenGL
212:
1.1.1.7 root 213: - Check/clean RS232 code:
214: - polls at 2/20ms intervals and reads data byte at the time.
215: SDL_Delay()s & fgetc() could be replaced (at least on unix)
216: with select() and fread(). Or just remove the rs232 thread
217: and use an interrupt for it...
218: - The commented out rs232 stuff could be removed from gemdos.c
219: (RS emulation is done at HW, not Gemdos level).
220:
221: - Improve directory handling:
222: - Currently screenshots & anim go always to current dir,
223: whereas memsave, sound recording, printer & midi & serial &
224: output and log output go to file specified in config file.
225: There should be support for setting also anim/screenshot
226: directory / file name from config file (needs change also
227: in screenSnapShot.c).
228: - By default the directory config values should be empty in
229: which case the code will at run-time decide to use current
230: directory, but not modify the path config setting.
1.1.1.9 root 231:
232:
233: Bug reports
234: -----------
235:
1.1.1.11 root 236: - Atari programs can crash Hatari in Falcon mode because sound DMA code isn't robust
237: against bad register values:
238: http://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2012/02/msg00082.html
239:
1.1.1.9 root 240: - When playing Tautology 2 I noticed the mod player sound goes in and out of
241: sync. fading into crackle and back. (Using Hatari 1.4 with TOS 4.04 on Mac
242: OS X 10.6.5)
243: http://developer.berlios.de/bugs/?func=detailbug&bug_id=17781&group_id=10436
244:
245: - Problem: On real Falcon there is a minor feature in videl. You can simply
246: fade whole screen to black, if you just clear the Horizontal Border End
247: ($ffff8286) and start fading colors from 0 to 255 to $ffff9800 or vice versa.
248: test <put picture to screen>
249: move.w #255-1,d7
250: moveq #0,d6
251: .loop <vsync, stop#$2300>
252: clr.w $ffff8286.w
253: move.l d6,$ffff9800.w
254: addq.l #1,d6
255: dbf d7,.loop
256: Now it does this exactly opposite direction, it fades bgcolor from 0 to 255.
257: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18002&group_id=10436
258:
259: - To compare my real Falcon with Hatari on my Windows 7 PC, I make some short
260: benchmarks with Kronos. The disk benchmark in Kronos runs in 1-2 minutes on
1.1.1.10 root 261: my real Falcon. The same disk benchmark in Kronos under Hatari 1.5 runs
262: longer than 20 minutes with GEMDOS emulation. Only when I use the AltGr + X
263: option, before the benchmark runs, then the disk benchmark in kronos is
264: comparable fast as my 16MHz Falcon.
1.1.1.9 root 265: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18298&group_id=10436
1.1.1.10 root 266:
267: -> Hatari GEMDOS emulation needs to do a lot of extra kernel file & directory
268: accesses which with current code seem unavoidable. They're a problem only
269: with test programs like Kronos, for those one should consider using
270: harddisk image files instead.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.