[hatari-devel] Execution history debugger command

[Nicolas Pomarède]

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?

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.)

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