wishlist: Creating states from debugger and other bits, and one bug

[ref]

I recently used winuae debugger and luckily I accomplished my task, thank you Toni.

As I will do some more debugging in the future, I thought I might add my wishlist here-without any pressure:

I used latest official WinUAE 3.0 (2014.12.17) binary.

Debugger window isn't resizable. Console history pane is too tight and it always needs scrolling.

Creating Save States within the debugger: Sometimes you need to create states from a specific time, or load a state and enter debugger immediately. I used breakpoints to break into debugger, as savestates retain breakpoints. (it *sometimes* confuses if you set a breakpoint and load a savestate with breakpoint set -possible bug)

pause: is it possible to pause emulation from debugger (to go into properties (F12) menu and change disk, save a state etc.)

Break on Change: I couldn't manage to trigger C directive of w (watchmem) command. w 0 $222222 1 C does not trigger anything. As I never used any hardware like actionreplay, I don't know how these triggers work. A little bit more documentation is more than welcome. I also couldn't found any change between R and W directives. They both trigger on read and write. Eg. w with W directive breaks on when only a read is made. it may be a bug or my misunderstanding of 68k code.

w command for registers: is it possible to set a trigger on a register?

[B]g command does not set focus to main window:[B/] You need to use mouse to click on main emulation window and hit Shift+F12 to activate debugger again.

Lastly, a real bug: it always crashed when I want to copy an address from 'A' registers: click on a register to edit the address, while the area is editable click on another window eg.browser, when you try to get back to winuae, it hangs (win7 x64). image: http://prntscr.com/5ufo6v

[Toni Wilen]

Originally Posted by ref

Debugger window isn't resizable. Console history pane is too tight and it always needs scrolling.

GUI debugger unfortunately is not supported by me, it was not done by me and I don't need or use it. I only use console one (use xx command to switch between them).

Creating Save States within the debugger:

Not possible. (Working) state file can be only created when emulated hardware is at the start of frame (vertical position = 0 and horizontal position = 0)

pause: is it possible to pause emulation from debugger (to go into properties (F12) menu and change disk, save a state etc.)

I thought I had added input event injection command to debugger but I guess I forgot..

Break on Change: I couldn't manage to trigger C directive of w (watchmem) command. w 0 $222222 1 C does not trigger anything. As I

You also need to tell it to do read or write check. It isn't that logical

"w 0 222222 1 w c" will work.

write. Eg. w with W directive breaks on when only a read is made. it may be a bug or my misunderstanding of 68k code.

Works for me. Need more information.

w command for registers: is it possible to set a trigger on a register?

No and I am not sure if it is that useful.

[ref]

Originally Posted by Toni Wilen

I only use console one (use xx command to switch between them).

Lol, I thought "what's this, it may be an old feature from UAE which Toni forgot to remove" when I switched to console Ok, I'll try again

Originally Posted by Toni Wilen

Not possible. (Working) state file can be only created when emulated hardware is at the start of frame (vertical position = 0 and horizontal position = 0)

Bummer May I ask why is that (if it's easy to answer)? PC and other pointers are recorded, you can save output image buffer and then can't you resume from last PC?

Originally Posted by Toni Wilen

I thought I had added input event injection command to debugger but I guess I forgot..

That'll work

Originally Posted by Toni Wilen

You also need to tell it to do read or write check. It isn't that logical

"w 0 222222 1 w c" will work.

oh, right

Originally Posted by Toni Wilen

Works for me. Need more information.

I'll check carefully again and report here.

Originally Posted by Toni Wilen

No and I am not sure if it is that useful.

Well, I wanted to step through until an instruction with a special register is used which does not modify any address. eg. move.l d2,d4 , and yes I managed to debug the code without that functionality, but it added too many flow control and time. And I know adding too many debugger checks may slow down the emulation.


Thanks Toni for your continuing support on winuae

[Toni Wilen]

Originally Posted by ref

Bummer May I ask why is that (if it's easy to answer)? PC and other pointers are recorded, you can save output image buffer and then can't you resume from last PC?

There is HUGE amount of internal state information that would need to be saved and restored if bitmap or sprite or copper DMA is active. Beginning of frame is the easiest position to handle. (audio, disk and blitter still needs to be saved and restored and it is already too complex)

It is not going to happen, it would also make statefiles practically incompatible between versions. Saved information would not anymore contain actual emulated hardware state but some emulator internal variables that keep changing between versions. And complexity of already complex bitplane and sprite emulation would get even more complex to support restoring state to midle of scanline.

[Nekoniaow]

Originally Posted by Toni Wilen

There is HUGE amount of internal state information that would need to be saved and restored if bitmap or sprite or copper DMA is active. Beginning of frame is the easiest position to handle. (audio, disk and blitter still needs to be saved and restored and it is already too complex)

It is not going to happen, it would also make statefiles practically incompatible between versions. Saved information would not anymore contain actual emulated hardware state but some emulator internal variables that keep changing between versions. And complexity of already complex bitplane and sprite emulation would get even more complex to support restoring state to midle of scanline.

Am I right to assume you mean that it won't happen without massive external help to re-architecture how emulator state is handled so that Amiga-related state data and emulation-specific state data are separated? (State file incompatibility problems aside.)

And if so, would you mind a hand in assisting in this re-architecture?
Note that this is not a proposal, I have my hands full with my current project but I am very curious about UAE's architecture and it's something I might be interested in in the future so I thought it didn't hurt to ask.

[B14ck W01f]

Originally Posted by ref

I recently used winuae debugger and luckily I accomplished my task, thank you Toni.

As I will do some more debugging in the future, I thought I might add my wishlist here-without any pressure:

I used latest official WinUAE 3.0 (2014.12.17) binary.

Debugger window isn't resizable. Console history pane is too tight and it always needs scrolling.

Creating Save States within the debugger: Sometimes you need to create states from a specific time, or load a state and enter debugger immediately. I used breakpoints to break into debugger, as savestates retain breakpoints. (it *sometimes* confuses if you set a breakpoint and load a savestate with breakpoint set -possible bug)

pause: is it possible to pause emulation from debugger (to go into properties (F12) menu and change disk, save a state etc.)

Break on Change: I couldn't manage to trigger C directive of w (watchmem) command. w 0 $222222 1 C does not trigger anything. As I never used any hardware like actionreplay, I don't know how these triggers work. A little bit more documentation is more than welcome. I also couldn't found any change between R and W directives. They both trigger on read and write. Eg. w with W directive breaks on when only a read is made. it may be a bug or my misunderstanding of 68k code.

w command for registers: is it possible to set a trigger on a register?

[B]g command does not set focus to main window:[B/] You need to use mouse to click on main emulation window and hit Shift+F12 to activate debugger again.

Lastly, a real bug: it always crashed when I want to copy an address from 'A' registers: click on a register to edit the address, while the area is editable click on another window eg.browser, when you try to get back to winuae, it hangs (win7 x64). image: http://prntscr.com/5ufo6v

You know, there is already a thread designed for requests like this. Just saying.

[Toni Wilen]

Originally Posted by Nekoniaow

Am I right to assume you mean that it won't happen without massive external help to re-architecture how emulator state is handled so that Amiga-related state data and emulation-specific state data are separated? (State file incompatibility problems aside.)

And if so, would you mind a hand in assisting in this re-architecture?
Note that this is not a proposal, I have my hands full with my current project but I am very curious about UAE's architecture and it's something I might be interested in in the future so I thought it didn't hurt to ask.

Not going to happen until display DMA stuff is completely understood, including all hidden internal hardware flags. (It is much more complex than "ddfstrt passed" and "ddfstop passed" and OCS and ECS also work quite differently even if results appear to be mostly same. I have many test cases that prove it)

Currently emulation has too many flags, I am quite sure real hardware is simpler. If current flags are stored to statefile, it forces emulation to stay compatible with them (even if it is totally wrong) or other choice is statefile that breaks between versions. I can't accept either one.

Scanline based state file support is more possible. (vpos can be anything but hpos must be zero). Much less unknown state to save.

[Nekoniaow]

Originally Posted by Toni Wilen

Not going to happen until display DMA stuff is completely understood, including all hidden internal hardware flags. (It is much more complex than "ddfstrt passed" and "ddfstop passed" and OCS and ECS also work quite differently even if results appear to be mostly same. I have many test cases that prove it)

Currently emulation has too many flags, I am quite sure real hardware is simpler. If current flags are stored to statefile, it forces emulation to stay compatible with them (even if it is totally wrong) or other choice is statefile that breaks between versions. I can't accept either one.

Scanline based state file support is more possible. (vpos can be anything but hpos must be zero). Much less unknown state to save.

Oh, I see. I thought that was more a code design issue but it's indeed very sound to avoid relying on emulator side state since it's bound to change as the knowledge of the underlying hardware changes.

With emulator side state you cannot guarantee that a statefile can be converted safely since future knowledge could make it invalid and not obviously convertible.

This said, there's a way to cheaply store a statefile at whichever cycle is desired without storing any emulator state:
- Record state at the last VBL here it's safe. (Business as usual.)
- Record all "external" inputs between state record and current cycle (human inputs: mouse, keyboard, all human inputs essentially) and the cycle at which they were first known (I guess they are emulated at the beginning of the frame though but let's assume they can happen anytime.).
- Record the current clock cycle number since the recorded state.
And that's it.

After the state is loaded, you just set the inputs at the time they were recorded while playing all cycles in cycle exact mode until you reach the expected clock cycle. If UAE is deterministic then you will be in the exact state the emulator was paused in, if it's not then well it's a bug right?

Of course this works only with stock hardware or if you also have the whole state of any signal-generating external hardware. How do you do for hard drives at the moment? Are they virtualized or also emulated?