From Newsgroup: comp.emulators.apple2

I was just the other day running a "drawing program" I wrote in Applesoft with supporting machine-language double-hires drawing routines, for double hires graphics on an actual Apple IIe, and it worked fine. The function of the program includes switching between displaying an image on double hires page 1, and viewing a 'toolbox' screen of standard lores graphics page 1, and back again, and it works without any problem.
Then I ported the program and double hires routines in the exact form that was working on my Apple IIe, to AppleWin on my Windows-based PC, where I find that while a double hires image initially looks just as it is supposed to, when I run my 'drawing' program displaying a double hires page 1 image, and switch to the lores page display, and then switch back, the double hires display no longer looks right; the colors are distinctly degraded and wrong. Then when I switch the display back and forth AGAIN, the double hires has no color AT ALL rCo it's totally black and white. Any further switching back and forth continues to display double hires in monochrome, and indeed, anything else I put into double hires is displayed monochrome, and I know of no way to restore the normal color of double hires short of shutting down AppleWin and re-launching it.
Why does double hires that displays perfectly on an actual Apple IIe go wrong in AppleWin? What can I do to keep it displaying correctly?
And as a side note, is there some way to attach a jpeg image to a message post here? I have an AppleWIn screen capture image showing the three stages of AppleWin double hires display: correct, degraded color, and no color, that I'd like to attach to show the problem I'm talking about.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Thursday, April 27, 2023 at 11:45:46rC>PM UTC-7, Alan Rat wrote:

Why does double hires that displays perfectly on an actual Apple IIe go wrong in AppleWin?

Before you open a bug report on GitHub can you report the order of soft-switches you're hitting please? Start AppleWin then
* press F7 to enter the debugger,
* type: BPM C050:C05F
* press Enter,
* type: BPM C00C:C00D
* press Enter, and
* press F7 again to exit the debugger, then
* Run your program.
AppleWin will switch back into the debugger when a softswitch (within the range specified above) is triggered. You can continue your program by pressing F7 (or alt. typing G and pressing Enter.)

And as a side note, is there some way to attach a jpeg image to a message post here?

No, Usenet does not support binary attachments (thank god), only text. You must either:
1. Encode the binary to text (e.g. uuencode), or
2. Upload it to an image hosting site (e.g. imgur) and then share the URL.

I'd like to attach to show the problem I'm talking about.

Opening a bug report on GitHub will let you attach your program, disk image, and screenshots if we can't diagnosis the issue here.
https://github.com/AppleWin/AppleWin/issues/new
Thanks,
Michael
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Friday, April 28, 2023 at 8:29:10rC>AM UTC-7, Alan Rat wrote:

I can tell you that my program starts off with PRINT CHR$(4)"PR#3":PRINT (via DOS 3.3) --> C00D
then the statement POKE 49246,PEEK(49239)=PEEK(49234) which triggers in the order C057 C052 C05E
and then POKE49232,0 for C050
C050 is then in effect all during execution, never C051
Double hires is thus displayed. When the program goes to the lores display, it issues:
PRINT CHR(17); which sets C00C
then the statement POKE 49238,PEEK(49247)=PEEK(49235) for C05F C053 C056
To return to double hires, it issues
PRINT CHR(18); which sets C00D
and again uses POKE 49246,PEEK(49239)=PEEK(49234) for C057 C052 C05E
and double hires is back, without any problem on an actual Apple IIe, but not so well in AppleWin.

I'm wondering if no one was ever previously aware of AppleWin displaying double hires in monochrome...?

This is AppleWin's emulation of the Video-7 / AppleColor / Le Chat Mauve RGB card protocol for DHR mono and other modes. If you switch your video setting from RGB to another (e.g. Composite) this problem will go away. Or change your program so that it exits/re-enters graphics mode before hitting the softswitches in order.
As you noticed, the modes are activated by loading a bit into 80COL and then turning AN3 off/on to shift the bit into a 2-bit register.
Mode 1 - Monochrome 560 x 192
Write $C00C (80COL off) - loads 0
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 0 into register
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 0 into register
Write $C00D (80COL on)
Write $C05E (AN3 off) - re-enable DHGR
Mode 2 - Color 140 x 192
Write $C00D (80COL on) - loads 1
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 1 into register
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 1 into register
Write $C05E (AN3 off) - re-enable DHGR
There's also weird Mode 3 (shift in 0 then 1), where the otherwise unused high bits of each DHGR byte set the output to monochrome (0) or color (1). This is detailed in the Video-7 RGB manual or Apple's "Extended 80-Column Text/AppleColor Adaptor Card" manual - they all follow the same protocol.
More details https://github.com/AppleWin/AppleWin/issues/523 and follow-on issues.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

Thank you very much for that information, Joshua! With it I was able to solve the problem. I didn't want the proper operation of my program to depend on NOT choosing RGB, so I incorporated the soft-switchiing succession you indicated, and that took care of it.
I had happened to choose RGB in the first place just because I liked the way it looked. I see now that the AppleWIn help file does mention that with RGB, double hires is 140x192 pixels (color) "or software selectable as: B&W or mixed Color/B&W", but it doesn't warn you that it may becoime monochrome unintentionally, or what to do to get color back if that should happen. It does go on to say that "Some double hi-res titles may have compatibility issues", after which it refers to "Troubleshooting", although that only cites three specific brand-name situations, and only offers a solution for the first of them, which was a different problem. In the end, though, it was good to be using RGB, as it's just as well to know where there could be a problem, and work around it. As I said, I didn't want my program to be beholden to the choice of video option.
Alan
On Friday, April 28, 2023 at 11:38:32rC>AM UTC-4, Joshua Bell wrote:

On Friday, April 28, 2023 at 8:29:10rC>AM UTC-7, Alan Rat wrote:

I can tell you that my program starts off with PRINT CHR$(4)"PR#3":PRINT (via DOS 3.3) --> C00D
then the statement POKE 49246,PEEK(49239)=PEEK(49234) which triggers in the order C057 C052 C05E
and then POKE49232,0 for C050
C050 is then in effect all during execution, never C051
Double hires is thus displayed. When the program goes to the lores display, it issues:
PRINT CHR(17); which sets C00C
then the statement POKE 49238,PEEK(49247)=PEEK(49235) for C05F C053 C056 To return to double hires, it issues
PRINT CHR(18); which sets C00D
and again uses POKE 49246,PEEK(49239)=PEEK(49234) for C057 C052 C05E
and double hires is back, without any problem on an actual Apple IIe, but not so well in AppleWin.

I'm wondering if no one was ever previously aware of AppleWin displaying double hires in monochrome...?

This is AppleWin's emulation of the Video-7 / AppleColor / Le Chat Mauve RGB card protocol for DHR mono and other modes. If you switch your video setting from RGB to another (e.g. Composite) this problem will go away. Or change your program so that it exits/re-enters graphics mode before hitting the softswitches in order.

As you noticed, the modes are activated by loading a bit into 80COL and then turning AN3 off/on to shift the bit into a 2-bit register.

Mode 1 - Monochrome 560 x 192
Write $C00C (80COL off) - loads 0
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 0 into register
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 0 into register
Write $C00D (80COL on)
Write $C05E (AN3 off) - re-enable DHGR

Mode 2 - Color 140 x 192
Write $C00D (80COL on) - loads 1
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 1 into register
Write $C05E (AN3 off)
Write $C05F (AN3 on) - shifts 1 into register
Write $C05E (AN3 off) - re-enable DHGR

There's also weird Mode 3 (shift in 0 then 1), where the otherwise unused high bits of each DHGR byte set the output to monochrome (0) or color (1). This is detailed in the Video-7 RGB manual or Apple's "Extended 80-Column Text/AppleColor Adaptor Card" manual - they all follow the same protocol.

More details https://github.com/AppleWin/AppleWin/issues/523 and follow-on issues.

--- Synchronet 3.21b-Linux NewsLink 1.2