Re: [hatari-devel] Debugger FPU bug ?

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


Am Mon, 10 Feb 2020 22:46:02 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 10/02/2020 à 00:02, Eero Tamminen a écrit :
> > Hi,
> > 
> > Ok, so it's the external disassembler which is
> > buggy.

Again... Sigh, it's really annoying to maintain this piece of code :-(

> > Nicolas, where we are with removing the external
> > one, once the UAE core one gets features that
> > were missing from it?  

The deprecation note has been added in commit c79254943 - that was
after the release of version 2.2.1. So we should still keep it for at
least one more public release that the users have the possibility to
read the deprecation note before we remove it.

By the way, Nicolas, it's been more than one year now since the last
release, what do you think about doing a new release soon?

> I don't remember if it was decided to drop it completely, but at
> least we can make internal WinUAE cpu core disassembler the default
> now, as it was much improved lately (MMU and FPU opcodes) and should
> now be more accurate than external disassembler in all cases.
> 
> Note that external disassembler can still be useful in the sense that 
> its output can be more or less recompiled with devpac for example. On 
> the opposite WinUAE's internal debugger add many useful infos (memory 
> content, effective address display), but this can make each disasm
> line not directly assemblable without editing it first.
> 
> For now, maybe it's just enough to change this line in configuration.c
> 
> ConfigureParams.Debugger.bDisasmUAE = false
> 
> and to use 'true' instead of 'false'

Good idea, I've just commited a patch for this now.

 Thomas



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