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

Screen flicker in full-speed mode #405

Closed
tomcw opened this Issue Apr 23, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@tomcw
Contributor

tomcw commented Apr 23, 2017

From cea2, James Davis, "AppleWin 1.26.1.1 Screen Flicker", (22 Apr '17):

I keep having to go back to AppleWin 1.25.0.4 because the last couple of times I downloaded newer versions like the latest stable release 1.26.1.1, I get some kind of HiRes flicker on the upper portion of the 40 column text screen. I am running it on a Microsoft Windows 7/64 PC. Will this bug be corrected in the next stable release?

(Tom) Please can you give precise repro steps so that we can investigate this?

I would have to reinstall that newer version to be exact, but from recollection, I just boot-up (slot 7) ProDOS and System Utilities, then drop out into Applesoft and press any key and it starts flickering from where a typed to the left and above randomly. I usually run at max speed, too; but I am not sure if the flicker does not happen at normal speed, also. I am usually trying to type CATALOG, first. I just stop right there and reinstall the old version.

I am running AppleWin as an Enhanced Apple IIe. Nothing added, no additional cards in any other slots than what comes standard with AppleWin. I have the Hard Disk Drive in slot 7 enabled, the 5.25" Floppy Disk Drive in slot 6, and the Printer in slot 1. I think there is a /RAM/ disk, but it does not seem to work. I do not know how to add slot cards to AppleWin, nor how to modify it in any way other than the configuration control-panel that it comes with. [It is not like AGAT in that sense. But, AGAT does not work with standard disk images, so AGAT is not a good emulator because of that.] I do not use the sound features at all. AppleWin does not sound right at high speed, and I do not want to hear anything from it, anyway. I would like to know how to make AppleWin emulate exactly my real Enhanced Apple IIe hardware, but I do not know how.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 23, 2017

Contributor

I think I am able to reproduce this by simply:

  • Config: Machine = Enhanced Apple //e
  • Config: CPU speed = max
  • Boot Tests-Various.dsk (from the AppleWin-Test repo)
  • CTRL+C and LIST
  • then just watching and every ~1 second there will be a single glitched horizontal line
Contributor

tomcw commented Apr 23, 2017

I think I am able to reproduce this by simply:

  • Config: Machine = Enhanced Apple //e
  • Config: CPU speed = max
  • Boot Tests-Various.dsk (from the AppleWin-Test repo)
  • CTRL+C and LIST
  • then just watching and every ~1 second there will be a single glitched horizontal line
@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 23, 2017

Contributor

The problem is when in full-speed mode, the display is updated every ~17ms. The V/H video scanner position is recalculated just before the whole screen update is done (based on dwCyclesThisFrame), but this new V/H pos won't be a continuation from the previous V/H pos. The horizontal glitch is the result of the V/H pos being wrong for the initial line.

So NTSC_VideoRedrawWholeScreen() needs fixing so that the redraw occurs from the start of the line & reinits the line vars.

Here's a screenshot of a glitch (V=54, H=2)
tests-various_000000050

Contributor

tomcw commented Apr 23, 2017

The problem is when in full-speed mode, the display is updated every ~17ms. The V/H video scanner position is recalculated just before the whole screen update is done (based on dwCyclesThisFrame), but this new V/H pos won't be a continuation from the previous V/H pos. The horizontal glitch is the result of the V/H pos being wrong for the initial line.

So NTSC_VideoRedrawWholeScreen() needs fixing so that the redraw occurs from the start of the line & reinits the line vars.

Here's a screenshot of a glitch (V=54, H=2)
tests-various_000000050

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 23, 2017

Contributor

In VideoRedrawScreenDuringFullSpeed() the screen only gets redrawn if the Apple II's video memory has changed.

Another repro: From 40-col, issuing a PR# 3 command will clear the screen, but sometime a (glitched) horizontal line can get left. If there's no further change to this video memory (eg. no key is pressed) then this line remains there.

It's simpler to just remove the code to check for video memory changes and redraw every ~17ms.

And on doing this, the timings(*) for AZTEC.DSK boot times remain the same (cf #347):

  • TV Color = ~1950ms
  • Mono Amber = ~1900ms

(*) Using my desktop PC (Win7-64, AMD Phenom II dual-core @3ghz).

Contributor

tomcw commented Apr 23, 2017

In VideoRedrawScreenDuringFullSpeed() the screen only gets redrawn if the Apple II's video memory has changed.

Another repro: From 40-col, issuing a PR# 3 command will clear the screen, but sometime a (glitched) horizontal line can get left. If there's no further change to this video memory (eg. no key is pressed) then this line remains there.

It's simpler to just remove the code to check for video memory changes and redraw every ~17ms.

And on doing this, the timings(*) for AZTEC.DSK boot times remain the same (cf #347):

  • TV Color = ~1950ms
  • Mono Amber = ~1900ms

(*) Using my desktop PC (Win7-64, AMD Phenom II dual-core @3ghz).

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Apr 24, 2017

Contributor
Contributor

sicklittlemonkey commented Apr 24, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 24, 2017

Contributor

I.e. this would probably be worse for WINE.

TBH, the logic to only redraw the Apple II screen if the Apple II's video memory had changed wasn't particularly good. I had tuned it for the HGR pages (so eg. not for TEXT or DHGR): eg. if on HGR1, then copy HGR1; then next time memcmp() HGR1. If changed then whole screen update, else do nothing.

For the non-HGR case the code would copy all video memory (aux/main: TEXT1/2, HGR1/2) and then memcmp() this at the next ~17ms interval. If any of this video memory had changed, then it'd do a whole screen update.

I will disable this logic for now. If there are complaints from Wine users then we can reconsider this code.


I notice there's a flash bug (flash slows down when holding Scroll-Lock)

Yes, you're right this is a bug that I hadn't noticed! When running in full-speed, the NTSC code isn't called every opcode (as you know). The updateFlashRate() function is called when the (NTSC) video scanner's V-pos wraps back to zero and needs to be called 16 times to toggle the flash state.

In full-speed, this function is only called once every ~17ms (ie. when NTSC_VideoRedrawWholeScreen() is called), so the flash rate will become ~17*16 = ~272ms (#) when it should be 16/60 = 267ms.

(#) This ~17ms interval is generated by GetTickCount() so there's probably more error creeping in to mean that the flash interval is longer than ~272ms.

Contributor

tomcw commented Apr 24, 2017

I.e. this would probably be worse for WINE.

TBH, the logic to only redraw the Apple II screen if the Apple II's video memory had changed wasn't particularly good. I had tuned it for the HGR pages (so eg. not for TEXT or DHGR): eg. if on HGR1, then copy HGR1; then next time memcmp() HGR1. If changed then whole screen update, else do nothing.

For the non-HGR case the code would copy all video memory (aux/main: TEXT1/2, HGR1/2) and then memcmp() this at the next ~17ms interval. If any of this video memory had changed, then it'd do a whole screen update.

I will disable this logic for now. If there are complaints from Wine users then we can reconsider this code.


I notice there's a flash bug (flash slows down when holding Scroll-Lock)

Yes, you're right this is a bug that I hadn't noticed! When running in full-speed, the NTSC code isn't called every opcode (as you know). The updateFlashRate() function is called when the (NTSC) video scanner's V-pos wraps back to zero and needs to be called 16 times to toggle the flash state.

In full-speed, this function is only called once every ~17ms (ie. when NTSC_VideoRedrawWholeScreen() is called), so the flash rate will become ~17*16 = ~272ms (#) when it should be 16/60 = 267ms.

(#) This ~17ms interval is generated by GetTickCount() so there's probably more error creeping in to mean that the flash interval is longer than ~272ms.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 24, 2017

Contributor

I've built, tested and pre-released a new AppleWin 1.26.2.3 version here.

Contributor

tomcw commented Apr 24, 2017

I've built, tested and pre-released a new AppleWin 1.26.2.3 version here.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 26, 2017

Contributor

On cea2, James Davis confirmed this version fixes the issue:

OK, the screen flicker is gone

Closing.

Contributor

tomcw commented Apr 26, 2017

On cea2, James Davis confirmed this version fixes the issue:

OK, the screen flicker is gone

Closing.

@tomcw tomcw closed this Apr 26, 2017

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Oct 29, 2017

Contributor
Contributor

sicklittlemonkey commented Oct 29, 2017

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