AppleWin erroneously generating tons of screenshots

[tomcw]

Willi / A2CPM on cea2 group, "AppleWin 1.30.0 and supported Windows versions":

AppleWin 1.30.0, for some reason to be determined, is generating tons of bit maps.

[Tom] Sounds very odd! Do you mean lots of screenshots? As if someone is pressing the PrintScreen key?

Yes. Version 1_28_0_6 also runs slowly so I assume the same thing happens w/ that version. Nothing resting on the keyboard for all four runs.

I have many versions of AppleWin installed on my XP system. The last four are versions 1_21_1, 1_25_0_4: 7, 1_28_0_6 and 1_30_0. With the first two versions listed the the assembly runs in 7 seconds. With the latter two it takes minutes. The XP system is no longer connected to the I'net so transferring files out of it will require the use of sneakernet.

NB. The slowness reported here is due to the erroneous screenshotting!

[wilserv]

AW.zip
src.hdv -> s7, d1 me.hdv -> S7, d2
click on upper right corner
Enter 'cd tp' then enter 'al'

[tomcw]

Thanks @wilserv, I'll take a look at this.

[tomcw]

A quick check:

• at normal speed (1MHz) it takes just over 3 mins to execute the al command
• at full speed on my PC, it takes ~3s to execute!

I'm not seeing any screenshots generated, unless I manually press the PrintScrn key.

One thing worth trying to using the -no-printscreen-key switch with AppleWin, which prevents the PrintScreen key from being registered, eg:

> applewin.exe -no-printscreen-key

[wilserv]

On Sun, Jun 20, 2021 at 4:39 AM TomCh wrote: A quick check: - at normal speed (1MHz) it takes just over 3 mins to execute the al command - at full speed on my PC, it takes ~3s to execute! I'm not seeing any screenshots generated, unless I manually press the PrintScrn key. One thing worth trying to using the -no-printscreen-key switch with AppleWin, which prevents the PrintScreen key from being registered, eg: > applewin.exe -no-printscreen-key

It's disappointing that you can't duplicate the problem I'm experiencing. Thanks for taking the time to investigate. I'll just avoid the problem by using version 1_25_0_4:. Willi

[tomcw]

It's disappointing ...

Yeah, I agree. Maybe it's a Windows XP related thing? I can only test as far back as Windows 7.

btw, I would have thought the "-no-printscreen-key" switch (added at AppleWin 1.27.0.0) would've worked. Can you confirm you tested it?

[wilserv]

On Sun, Jun 20, 2021 at 3:52 PM TomCh wrote: Yeah, I agree. Maybe it's a Windows XP related thing? I can only test as far back as Windows 7. btw, I would have thought the "-no-printscreen-key" switch (added at AppleWin 1.27.0.0) would've worked. Can you confirm you tested it?

Well, I screwed up BIG time. When I found that huge number of bitmaps I did NOT check the dates that they were generated. I simply erased them and assumed that they were the source of the problem. I just ran the assembly and NO bitmaps are generated. Please accept my sincere apology for having wasted your time. Willi

[tomcw]

@wilserv - no problem... but don't you still have a case where newer versions run much slower (~10x ?) than older versions?

[wilserv]

Hi!

On Mon, Jun 21, 2021 at 4:44 PM Tom wrote: @wilserv <https://github.com/wilserv> - no problem... but don't you still have a case where newer versions run much slower (~10x ?) than older version

With version 1_25_0_4 the assembly takes 7 seconds. With versions 1_28_0_6 and 1_30_0 it takes 13 minutes. That's 100x Aha, just had an idea. I'll grab versions between 1_25 and 1_28 to see if I can find the version where the slowdown starts happening. Willi

[wilserv]

Hi! The assembly runs quickly in 25.0.3 and 25.0.4, slowly in 26.0.6 and 27.0.0. Willi

[tomcw]

@wilserv:

The assembly runs quickly in 25.0.3 and 25.0.4, slowly in 26.0.6 and 27.0.0.

The transition from 1.25.0.x to 1.26.0.0 was when we added NTSC & cycle-accurate video support, which had a big impact on speed, meaning it required the Windows PC to do more intensive processing.

With versions 1_28_0_6 and 1_30_0 it takes 13 minutes.

At 13 minutes, this is 4x slower than my 1MHz time of 3mins! So this implies that your XP system isn't fast enough to run emulation at 1MHz!

You can try running in full-speed mode (eg. CTRL+3 or use the Configuration UI) as this will only periodically update the video display. Use AppleWin 1.30.x for this.
(And use CTRL+1 to switch back to normal 1MHz mode.)

But it could just be that your XP system is too slow :-/

[wilserv]

Hi!

On Tue, Jun 22, 2021 at 2:41 PM TomCh wrote: @wilserv <https://github.com/wilserv>: The assembly runs quickly in 25.0.3 and 25.0.4, slowly in 26.0.6 and 27.0.0. The transition from 1.25.0.x to 1.26.0.0 was when we added NTSC & cycle-accurate video support, which had a big impact on speed, meaning it required the Windows PC to do more intensive processing. With versions 1_28_0_6 and 1_30_0 it takes 13 minutes. At 13 minutes, this is 4x slower than my 1MHz time of 3mins! So this implies that your XP system isn't fast enough to run emulation at 1MHz! You can try running in full-speed mode (eg. CTRL+0) as this will only periodically update the video display. Use AppleWin 1.30.x for this.

(And use CTRL+1 to switch back to normal 1MHz mode.)

I NEVER run at the normal 1MHz mode. Since 25 works very well for me I'll stay with it Willi

[tomcw]

Thanks @wilserv, it seems like you are fine with using 1.25.0.4 - in which case I will close this issue.