Re: [hatari-devel] Next Hatari release?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]



Any thoughts on next Hatari release?

What features you think should still be added before next release?

I think having the core respect the 68030 data cache would be nice - it would bring the performance of Hatari closer to the performance of a real 68030 under normal conditions. 

I am aware that demos tend to turn the d-cache off because it can improve performance - but this rule applies to block transfer cases which happen to dominate in those programs - in other cases where block transfers are less dominant, absence of d-cache can result in significant slowdown - especially in compiled code where local frame access or list/tree container processing can dominate.

I also find the purpose of some of the CPU control options on the UI unclear. For a user, it's hard to understand the consequences of changing them. This seems to stem from problems with orthogonality of features provided by the CPU cores? It's probably a difficult job to sort out those issues in the cores but some of it is UI presentation - I think it would be beneficial to improve this if possible (if not for the next release then at least incrementally).

It would be nice to have an 'unconstrained' emulation mode which uses all available host CPU time, allowing the emulated machine to operate with 'variable MHz' according to the performance of the host machine. i.e. the emulator still counts cycles the same way but doesn't attempt to limit 'cycles per frame' (or however it gets capped just now to match 8/16/32mhz).

There may be a loss of compatibility with time-critical areas (audio? dma? display?) but it would be very good for compiling or other intensive work on the emulated machine, especially if it can be toggled on/off with a keystroke. I suppose it would need a really fast host to benefit but it's worth thinking about. Note that DSP emulation would unlikely be required in such a 'mode' so toggling that off at the same time as the MHz cap would probably make sense too?

These points are again from a developer's perspective - probably less from gamer or typical user's perspective so there are probably higher priorities elsewhere. 

Can't think of anything else just now :)

D.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/