[hatari-devel] Execution history debugger command

[Deniz Turkoglu]

On Thu, Jun 2, 2011 at 11:28 AM, Nicolas Pomarède
<npomarede at corp.free.fr> wrote:
> Le 02/06/2011 01:15, Eero Tamminen a écrit :
>
>>>> (Wine isn't an emulator.  It provides Win32 API and emulates some
>>>> things, but the x86 code it runs directly.)
>>>
>>> Well, then as a principle, I'm afraid I can't help you there. I'm not
>>> asking you to install some commercial program, we're just talking about
>>> a very good ST emulator that many people still consider superior to
>>> Hatari because of its nice UI.
>>> It won't install viruses, just test it for one hour and remove if after
>>> that if you prefer.
>>
>> Before running it, does your version have same checksums as the version
>> I just downloaded:
>> $ md5sum Steem.exe steemupdate.exe unzipd32.dll
>> 7d89731bd2bade75cf973ccd308ed50f  Steem.exe
>> 259d0340504a80fdcb2371367c3e704f  steemupdate.exe
>> aaddb5561976f09c2d002d8ebc78d54d  unzipd32.dll
>
> Yes, I have the same md5sum for those files.
>
>
>> [...]
>>>>
>>>> If it's built into Hatari, I think it should be done with SDL[1].  This
>>>> limits the "UI" to the size of the Hatari screen (SDL provides just one
>>>> "framebuffer" as far as I know) which would complicate things because
>>>> Hatari window size changes often on Falcon emulation.
>>>>
>>>> [1] While embedding Hatari SDL stuff to OSX UI is already working I
>>>> think adding Qt to that mix would be a bad idea.
>>
>> I mean, I have some doubts about it working.  Has somebody successfully
>> mixed C++ Qt&  Objective-C Cocoa widgets in same program and succefully
>> built&  run it?

For the UI, there are also other alternatives. Qt is one, and I think
they are quite popular, but other one is wxWidgets that I know of. Of
course both has pros and cons, and of course SO has a discussion on
this:

http://stackoverflow.com/questions/2886258/wxwidgets-vs-qt

I haven't used many Qt backed programs but some famous ones --binary
blobs, are Skype and Google Earth on linux (afaik), KeepassX is open
source and is also built using Qt, and those would be ideal to have a
look at how Qt looks like.

wxWidgets look quite native, they have posted some screenshots on
http://www.wxwidgets.org/about/screensh.htm

> Well, if I recall correctly Vice and/or Openmsx are having different UI, I
> don't know if it's possible to mix qt/cocoa, but in that case it could be
> possible to make a QT only UI and use it also on OSX (if the user prefers it
> to the native osx look).
>
>>
>>
>>> Having SDL for the UI has the advantage of always being able to have all
>>> the settings on screen, even in fullscreen mode.
>>>
>>> But doing a debugger limited to the size of the SDL screen is too
>>> limited. Today, it's already complicated to add some options to the UI
>>> by taking care of the SDL window's size. At best we would have the same
>>> number of characters as in Monst, which is really limited considering
>>> most monitors go beyond 1280x1024.
>>
>> While the SDL debugger UI would be bound by the Hatari screen size, it
>> doesn't mean that the output would have to be scaled like the Atari screen
>> is.  Adding --desktop option support for ST mode too and running in
>> fullscreen would guarantee largest possible resolution.
>
> In my case running --desktop on a 1280x1024 monitor then pressing F11
> doesn't give that much more space (visually it looks the same as if I didn't
> use "--desktop 1")
>
>>
>>
>>> I think we could have the usual SDL UI for running Hatari and for
>>> example a QT UI with external/resizable/movable windows for the debugger.
>>>
>>>> As a separate program the UI could be any size and the size could be
>>>> fixed at startup.  Instead of separate windows, it could have e.g.
>>>> separate screens which are switched using e.g. function keys.
>>>
>>> I prefer having separate windows than many screens, because it implies
>>> you can have only one screen at a time, which is often a limitation if
>>> you want to have several hexa/asm dump visible at the same time to
>>> compare them.
>>
>> If Hatari would be running at e.g. 1280x1024, you could fit several
>> hex/asm
>> dumps on same screen...  How many of them you typically and at maximum
>> would
>> want to compare at the same time ?
>
> Do you mean emulating a 1280x1024 resolution in GEM ? But in that case it
> won't work with demos and games, and those are certainly the only candidates
> for a debugger.
>
>>
>> (With single window approach it might be possible to offer the same
>> UI both with SDL&  ncurses.  SDL can look nicer whereas ncurses on
>> console would support copy/paste.)

For debugging I have another idea, may it be radical or not feasible.
Browsers have been working on remote debugging for sometime, almost
all has an option; Chrome/Webkit : Remote Inspector, Firefox : Firebug
+ Crossfire, Opera : Scope.

http://www.webkit.org/blog/1620/webkit-remote-debugging/
http://getfirebug.com/wiki/index.php/Crossfire
http://dragonfly.opera.com/app/scope-interface/

I think a wire protocol would benefit Hatari as well, esp. for
debugging on devices, for instance N900. I have been checking the
options and couldn't decide on the protocol, mainly the serializer. I
am interested in using thrift (http://wiki.apache.org/thrift/Tutorial)
to remotely debug/control/test hatari but it doesnt support events out
of the box, which makes it a plain RPC and not fit for debugging. JSON
is of course an option but I really like google-protobuff or thrift,
mainly due to code generation and overall cleaner API that can be
built with them.

Having a clean protocol also means the UI can be done in any language,
thrift has bindings for almost every language and it would be easy to
build an UI that supports both local and remote debugging.

-deniz

> The problem with single window (everything in Hatari's current window) is
> that once in the debugger, you can't see the ST screen anymore. And when you
> want to debug colors/blitter or other gfx problems, it's very important to
> have the full Atari video screen visible, not overlapped by some other
> informations.
>
> I know lot of things can be made with ncurses, including using the mouse,
> but what if you want to resize some of those internal windows to make an
> hexa dump bigger/smaller for example ? You need to handle some kind of
> window resizing in ncurse. Same if you want to reorder/move those windows
> inside Hatari.
> Quite a nightmare in the end, reinventing the wheel in some ways, I don't
> think ncurse is the proper solution when you want to handle a variable
> number of windows, with different size and position.
>
> Having external windows seems really much more useful to me : you keep the
> Atari's video screen untouched and you have a bunch of windows locked on
> registers/asm/hex dump. You're not limited to Hatari's resolution, but you
> can benefit of all the space your OS is giving you (if you have dual monitor
> for example).
>
> Nicolas
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>