[hatari-devel] Main EmuTOS (games) compatibility issues that still remain

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 15 maaliskuu 2013, Vincent Rivière wrote:
> On 15/03/2013 19:53, Roger Burrows wrote:
> > But what instruction at what location sets 31dca to that value?
> 
> The program calls the Line A initialization $A00A and gets the routine
> vectors in a2. It gets the address of _v_hide_c, then starts doing crazy
> undocumented things with the bytes of the actual routine!
> 
> It seems that Ramses will never work on EmuTOS (without patching).

Thanks for investigation!  I updated the (Hatari) EmuTOS compatibility
list accordingly.


After this, I would conclude that the remaining, main EmuTOS
compatibility issues with (freely available) games are:
1) evnt_multi() issue that causes problems
   with mouse clicking and dragging
2) missing Line-A bitblt
4) missing 256-color & TC support
3) missing DSP Xbios calls support

First issue obviously affects only GEM programs, but it's a problem
on all machines and as it's a bug, not a missing feature, I would
think that first priority for compatibility.


Second issue also affects all machines as even some newly made
Falcon games (e.g. ones from Paradize) can still use line-A.
Supporting line-A (bitblit) would help largest number of games.

Bitblit is quite bothersome to implement though and while it
could probably share code with VDI, the APIs are annoyingly
different.  It being deprecated API also makes it less
interesting.


256-color mode affects TT applications in addition to Falcon
ones, but there are so few TT-specific ones that I think last
two items could be considered Falcon compatibility.

Because Firebee doesn't yet have DSP in FPGA, I would think
256-color & TC support more important than DSP support.


	- Eero