Skip to content
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

Debug screen is black "in front of" the beam #274

Open
mattgodbolt opened this issue Oct 4, 2019 · 5 comments
Open

Debug screen is black "in front of" the beam #274

mattgodbolt opened this issue Oct 4, 2019 · 5 comments

Comments

@mattgodbolt
Copy link
Owner

Hitting a breakpoint or ctrl-HOME now yields a black screen post-the virtual CRTC beam. To repro:

  • MODE 2
  • ctrl-s 0 4 0 0 0
  • hit ctrl-home
  • notice the screen post the beam location is black.

I think this is probably a result of the improvements to the CRTC emulation, but it's convenient to see the screen when debugging :)

Screenshot from 2019-10-04 07-48-38

@mattgodbolt
Copy link
Owner Author

@richtw1 quite likes this: maybe it should be configurable? or the "remaining" screen should be like 30% faded out or something?

@richtw1
Copy link
Collaborator

richtw1 commented Oct 4, 2019

I don't think I'd bother keeping it TBH. If it's more useful to see the entire screen then that's what it should do. Sometimes a million configurable options just needlessly complicates!

@richtw1
Copy link
Collaborator

richtw1 commented Oct 4, 2019

That said, this isn't obviously easy to fix, because it's an inevitable consequence of clearing the texture at the start, instead of blanking scanlines as they're rasterised. This gave a reasonable performance gain, so it would be a shame to put it back.

Other possibilities:

  • always pause when raster at the bottom of the screen (might lead to stopping in the same point in execution each time?)
  • separate pause / screenshot button (which doesn't enter the debugger, just waits until the bottom of the screen and then stops until you press Go again)

@mattgodbolt
Copy link
Owner Author

Agreed it's not an easy fix. Just taking these comments:

  1. Not really an option as "pause" is the same as breakpoint, and when debugging things it's also useful to know what's on the screen. In particular I use this a lot when I do presentations on jsbeeb (e.g. https://mattgodbolt.github.io/bbc-micro-emulation/avast/#/18 which I run on purpose to crash on the "undefined" opcode).
  2. This is cool for screenshots so 👍 but less useful in general for debugging.

Keeping the "old" screen around in a debug mode might be an option. I already have some (expensive) debugging things knocking around that are disabled by default, and so "keep old screen around when debugging" might be an option. So long as I can put ?debug or something in the URL I'll be happy :)

@mattgodbolt
Copy link
Owner Author

(that said the "old" screen around could be used to e.g. do phosphor simulation)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants