New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger G(o) command should use normal speed #217

Closed
sicklittlemonkey opened this Issue Jul 30, 2014 · 7 comments

Comments

Projects
None yet
3 participants
@sicklittlemonkey
Contributor

sicklittlemonkey commented Jul 30, 2014

Full-speed might have been needed in the past or in certain circumstances (trace?) but debugging emulation speed needs to be slowed down to 1MHz - usually because you need to control some game etc to hit a breakpoint.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 5, 2017

Contributor

As discussed in #384, I have started to support a revised g(o) and a new gg debugger command at these commits: 0b6c5bb and 743add8.

The "spec" (now extended to include speaker/Mockingboard sound) is:

command run at normal speed run at full speed video quality sound quality
g(o) yes only if disk active, etc precise(*) precise
gg no always periodic muted

Video quality: (*)

  • When running with g(o)
    • (normal speed), then it's assume there's enough PC time to render the video per 6502 cycle.
    • (full speed), then use periodic video update.
  • When running with gg (full speed), then use periodic video update.
Contributor

tomcw commented Mar 5, 2017

As discussed in #384, I have started to support a revised g(o) and a new gg debugger command at these commits: 0b6c5bb and 743add8.

The "spec" (now extended to include speaker/Mockingboard sound) is:

command run at normal speed run at full speed video quality sound quality
g(o) yes only if disk active, etc precise(*) precise
gg no always periodic muted

Video quality: (*)

  • When running with g(o)
    • (normal speed), then it's assume there's enough PC time to render the video per 6502 cycle.
    • (full speed), then use periodic video update.
  • When running with gg (full speed), then use periodic video update.

@tomcw tomcw self-assigned this Mar 5, 2017

@tomcw tomcw added this to the 1.27 milestone Mar 5, 2017

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Apr 13, 2017

Contributor

Tom, thanks for adding this patch. The go and gg are good additions.

Contributor

Michaelangel007 commented Apr 13, 2017

Tom, thanks for adding this patch. The go and gg are good additions.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 14, 2017

Contributor

There are still some edge-cases to straighten out, eg:

  1. In MODE_STEPPING (g mode) ESCape will exit back into the debugger.
    This means you can't use ESC to interact with the emulated Apple II.
    IMO we shouldn't treat ESC specially. Instead the user can use either press F7 or click the Debug button.

  2. Decide the behaviour for the cases when you do one of these actions:

  • CTRL+RESET (eg. CTRL+F2 or CTRL+BREAK)
    • This seems OK and doesn't seem to affect MODE_STEPPING
  • F2 (eg. reboot/power-cycle)
    • Currently this will just switch from MODE_STEPPING to MODE_RUNNING!
  • Loading a save-state
    • Consider: running game1 and I have some breakpoints setup, then I load the save-state for game2 (where the BPs no longer make sense). Is this acceptable?
  • Change configuration, eg. Apple II's h/w config
    • We probably want the same behaviour as loading a save-state.
Contributor

tomcw commented Apr 14, 2017

There are still some edge-cases to straighten out, eg:

  1. In MODE_STEPPING (g mode) ESCape will exit back into the debugger.
    This means you can't use ESC to interact with the emulated Apple II.
    IMO we shouldn't treat ESC specially. Instead the user can use either press F7 or click the Debug button.

  2. Decide the behaviour for the cases when you do one of these actions:

  • CTRL+RESET (eg. CTRL+F2 or CTRL+BREAK)
    • This seems OK and doesn't seem to affect MODE_STEPPING
  • F2 (eg. reboot/power-cycle)
    • Currently this will just switch from MODE_STEPPING to MODE_RUNNING!
  • Loading a save-state
    • Consider: running game1 and I have some breakpoints setup, then I load the save-state for game2 (where the BPs no longer make sense). Is this acceptable?
  • Change configuration, eg. Apple II's h/w config
    • We probably want the same behaviour as loading a save-state.
@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Apr 14, 2017

Contributor
Contributor

sicklittlemonkey commented Apr 14, 2017

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Apr 14, 2017

Contributor

Is it possible to turn off the debugger?

Nick, my long term plans are:

  • 6502 -- no debugger
  • 65c02 -- no debugger
  • 65d02 -- debugger

I'm willing to bet 80% of the users don't use (or even know) about the debugger. The few that do, can manually switch to the psuedo 65d02 CPU.

Contributor

Michaelangel007 commented Apr 14, 2017

Is it possible to turn off the debugger?

Nick, my long term plans are:

  • 6502 -- no debugger
  • 65c02 -- no debugger
  • 65d02 -- debugger

I'm willing to bet 80% of the users don't use (or even know) about the debugger. The few that do, can manually switch to the psuedo 65d02 CPU.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 14, 2017

Contributor

re. 65d02
Presumably you'll need variants for 6502 and 65C02?

Contributor

tomcw commented Apr 14, 2017

re. 65d02
Presumably you'll need variants for 6502 and 65C02?

tomcw added a commit that referenced this issue Apr 22, 2017

Debugger: When MODE_STEPPING (eg. g or gg mode), prevent ESC from exi…
…ting back to the debugger. F7 or Pause keys can still be used. (#217)

tomcw added a commit that referenced this issue Apr 22, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 22, 2017

Contributor

Closing this, as the above 2 commits address my comment from a week ago where I said:

There are still some edge-cases to straighten out

Contributor

tomcw commented Apr 22, 2017

Closing this, as the above 2 commits address my comment from a week ago where I said:

There are still some edge-cases to straighten out

@tomcw tomcw closed this Apr 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment