Re: [MiNT] Testing and debugging on emulators (was: GCC 4.4.3)

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Monday 01 February 2010, Jo Even Skarstein wrote:
> Yes, and yet you list a number of things that differs Hatari from the
> hardware it's emulating ;-) I'm not saying anything about the quality of
> Hatari or emulators in general, but they are not suited for final testing
> of software. This can only be done on the actual hardware the software is
> intended to run on.

Sure, for final testing it's better to be done on real HW, but if you're
worried about that level of accuracy, you better do that testing also on
several different machines as there are also differences between HW.  :-)


Doing initial fast testing on emulators is nice though and emulators offer
also additional possibilities for debugging.  A quote from one user:
-----
Problem of MonST/Adebog/TurboAss, etc... is that they interact with what
you are currently debugging. Typically an Atari ST demo uses a gazillion
of timers, replaces the VBL, cut the mfp, etc... and is totally impossible
to debug with MonST (monst dies as soon as the VBL is  disabled). You can do
it with Adebog in IPL/7, but then you have restrictions about what you can
do.
-----

Latest Hatari version debugger can now breakpoint on any change to
any memory location (or register value or value in address pointed by
register), or you can tell the breakpoints just trace those changes.
E.g. to trace joypad direction register changes:
	break ($ffff9202).w ! ($ffff9202).w trace

That feature was partly inspired by the odd stack address issue discussion
on this list. :-)


>> What is hard though, is getting a full MiNT distribution with latest SW
>> that doesn't rely on Aranym host drivers (fDVI etc) and is set ready for
>> use on real ST HW (68000).
>
> The real problem here is rather that FreeMiNT hasn't been working on
> 68000 for a long time... Also, lack of RAM would probably be a big
> problem.

Right.


	- Eero