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

560x192 B&W apps not always start in B&W mode #631

Closed
jvernet opened this issue Mar 19, 2019 · 27 comments

Comments

Projects
None yet
5 participants
@jvernet
Copy link

commented Mar 19, 2019

Hello,
I don't know if it's the best place to post, but as Applewin recently added a working 560x192 B&Wmode/Mixed Mode...

I'm doing some testing on how apps that support 560x192 B&W mode work on AppleWin (lats build), and my real hardware (Apple //e with Le Chat Mauve RGB card).

I don't know if there is a list of such app somewhere, but I found those:

  • MouseDesk/Apple II Desktop: start mostly in B&W mode, but not all version on Applewin. Some start in B&W mode in certain conditions. Always start in B&W mode on my Apple IIe.

  • A2desktop
    from https://github.com/inexorabletash/a2d always start in B&W mode both on AppleWin and Apple IIe.

  • Multiscribe/BeagleWrite:
    do not start in B&W mode on Applewin, but start in B&W mode on my Apple //e ONLY if launched from inexorabletash/a2d.

  • MousePaint:
    start in B&W mode on Apple IIe only for the french 1.1 version. not on AppleWin. 1.2 version start in B&W mode sometime on my Apple IIe.

  • Publishit 3 and 4: start in B&W mode both in AppleWin and Apple IIe

  • I tried another app from Broderbund (a paint program I forget the name), it's start in a mixed mode under my Apple IIe, but in B&W with glitches on AppleWin.

All these app will start in B&W mode with Sweet 16 or real IIgs

Is there any other app known to use this mode ?
Is there a way to have something consistent (may be setting before launching some memory location ?).

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

Hi, yes this is right place to discuss this. Thanks for testing with both AppleWin and real h/w. For the differences you list, I guess that the mode selection isn't quite right.

For the Broderbund paint program (Dazzle Draw?) can you describe the glitches in more detail, eg. how to reproduce.

There's a short list of titles that support this mode here

@jvernet

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

Yes, it's Dazzle Draw 1.2: I do not have these vertical bars on my IIe in the menu button.
Dazzle Draw

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I do not have these vertical bars on my IIe in the menu button.

Interesting!

Can you share a photo of your real IIe?

@jvernet

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

I will.
List of app using this B&W Mode: list to be completed

  • Apple II Desktop (various version) and MouseDesk
    Dazzle Draw
    MulstiScribe
    BeagleWrite
    MousePaint
    GS Font Editor
    Publishit 3 et 4
    Le Chat Mauve Extasie (paint in mixed mode)
    Le Chat Mauve Arlequin (Graphics interpreter/BASIC)
    Le Chat Mauve PURPLESOFT (DOS 3.3 BASIC &)

Some Games

@inexorabletash

This comment has been minimized.

Copy link

commented Mar 22, 2019

Sounds similar to inexorabletash/a2d#122 especially if A2D 1.1 and MouseDesk suffer from the issue but my A2D builds do not. I seem to have lost the actual discussion, but my fix involved not hitting the 80VID/AN3 switches until after DHR mode was already activated.I do not have original hardware (Le Chat Mauve, Video 7, AppleColor card) to test with, alas.

FWIW, the "old" A2D code hits switches in this order:

CLR80VID, AN3_OFF, AN3_ON, AN3_OFF, AN3_ON, SET80VID, AN3_OFF, DHIRESON, SET80VID, HIRES, PAGE1, MIXCLR, TXTCLR

My "new" A2D code hits them in this order:

DHIRESON, SET80VID, HIRES, PAGE1, MIXCLR, TXTCLR, CLR80VID, AN3_OFF, AN3_ON, AN3_OFF, AN3_ON, SET80VID, AN3_OFF

Seems like someone could put together a test app to narrow this down?

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 24, 2019

Reference code for DHGR mixed mode for La Chat Mauve:
http://boutillon.free.fr/Underground/Anim_Et_Graph/Extasie_Chat_Mauve_Reloaded/Extasie_Chat_Mauve_Reloaded.html#Annexe6

                75   DISPLAY
8040: 8D 50 C0  76                 STA    $C050     ; BRANCHE LA DHGR
8043: 8D 54 C0  77                 STA    $C054
8046: 8D 52 C0  78                 STA    $C052
8049: 8D 57 C0  79                 STA    $C057
804C: 8D 5D C0  80                 STA    $C05D
804F: 8D 0C C0  81                 STA    $C00C
8052: 8D 5E C0  82                 STA    $C05E
8055: 8D 5F C0  83                 STA    $C05F
8058: 8D 0D C0  84                 STA    $C00D
805B: 8D 5E C0  85                 STA    $C05E
805E: 8D 5F C0  86                 STA    $C05F
8061: 8D 5E C0  87                 STA    $C05E
                88
8064: 8D 08 C0  89                 STA    $C008
                90
8067: 2C 10 C0  91                 BIT    $C010     ; ATTEND UNE TOUCHE
806A: AD 00 C0  92   :1            LDA    $C000
806D: 10 FB     93                 BPL    :1
                94
806F: 8D 54 C0  95                 STA    $C054     ; déconnecte la DHGR
8072: 8D 51 C0  96                 STA    $C051
8075: 8D 56 C0  97                 STA    $C056
8078: 8D 0C C0  98                 STA    $C00C
807B: 8D 5F C0  99                 STA    $C05F
807E: 8D 01 C0  100                STA    SET80STORE
8081: 20 58 FC  101                JSR    HOME
8084: 60        102                RTS

EDIT: All these DHGR mixed-mode images display correctly as mixed B&W / Colour in AppleWin. I'm just including this reference for my information.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

  • MousePaint:
    start in B&W mode on Apple IIe only for the french 1.1 version. not on AppleWin.
    1.2 version start in B&W mode sometime on my Apple IIe.

I have tried all these MousePaint images from asimov, which are a mix of 1.0, 1.1 and 1.2 versions.
NB. The French version is 1.1.

French/apple_mousepaint_disks.zip
MousePaint (alt 2).dsk
MousePaint (alt 3).dsk
MousePaint 1.2 on 800k image.2mg
MousePaint Drawing Program for the IIc IIe II Plus and 64K II.dsk
mousepaint.dsk
Mousepaint_alt.dsk
mouse_paint.dsk

All are in HGR (not DHGR), and I set a VS breakpoint on the $C05E/F access and it only triggers once in Enhanced Apple //e ROM, at $C2B8.

Since none are using DHGR, then none will use the 560x192 B&W mode.

For reference, here is the French version:
mousepaint(french)

btw. if I enabled "Vertical Blend" (in AppleWin 1.28.4.0) then this alternating background becomes grey, but this is not what @jvernet is talking about.

@jvernet

This comment has been minimized.

Copy link
Author

commented Mar 26, 2019

About DazzleDraw: your right, menu have vertical blank lines, same for AppleWin.
For MousePaint 1.1: if launched via MouseDesk 2.0 1.1 French, here is what I got:
IMG_1482
A B&W MP, BUT NOT DHGR.
Launched directly, or from A2desktop:
IMG_1485

MP 1.2 do not do that.

About Le Chat Mauve Card:
-There is at least 2 (3 with the Apple //c adapter) card:

  • Le Chat Mauve EVE, wich support all Apple IIe modes EXCEPT Mixed Mode (560x192 Mixed), plus
  • 140x192 16 colors without constrainst,
  • 280x192 4 colors (Black, Orange, green, white or Black, Light Blue, pink, Yellow)
    -280x192 16 colors Background/foreground by 7 pixels (2 bits planes)
    -560x192 B&W only

Le Chat Mauve Feline, wich support only the standard Apple IIe modes and B&W Mixed Mode

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

Great, thanks for the pics!

So what is (likely) happening in the B&W MousePaint (MP) case is that the previous session (A2D) is enabling DHGR B&W mode, which is disabling color-burst. Then when you launch MP, Le Chat Mauve is still in this color-burst-disabled mode and so displays HGR in B&W.

This is easy to mimic - but does the Apple ColorCard is exhibit this behaviour? It's an edge case though.

@inexorabletash

This comment has been minimized.

Copy link

commented Mar 26, 2019

Just confirming: MD/A2D 1.1 do not disable mono mode when launching other programs, but my builds do, which matches the inferred behavior.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

I dumped out all the video soft-switch accesses (excluding $C054/5) for "old" A2D 1.1:
(NB. The PC is out by 3 since it's the value of the PC after completing the soft-switch access, but it's good enough. And VideoMode is AppleWin's internal bitfield just after the soft-switch access is done.)

$C056: PC=$FB36, VideoMode=00000040
$C051: PC=$FB3C, VideoMode=00000040
$C00E: PC=$CD8B, VideoMode=00000040
$C058: PC=$FA72, VideoMode=00000040 (not video)
$C05A: PC=$FA75, VideoMode=00000040 (not video)
$C05D: PC=$C2B8, VideoMode=00000040 (not video)
$C05F: PC=$C2BB, VideoMode=00000040 ; 0100 0000 = TEXT
$C001: PC=$CA9C, VideoMode=00000048
$C000: PC=$CAB7, VideoMode=00000040
$C00C: PC=$2628, VideoMode=00000040
$C000: PC=$262B, VideoMode=00000040
$C056: PC=$FB36, VideoMode=00000040
$C051: PC=$FB3C, VideoMode=00000040
$C001: PC=$2218, VideoMode=00000048
$C000: PC=$2236, VideoMode=00000040
$C00C: PC=$BD77, VideoMode=00000040
$C00E: PC=$BD7A, VideoMode=00000040
$C000: PC=$BD7D, VideoMode=00000040
$C056: PC=$FB36, VideoMode=00000040
$C051: PC=$FB3C, VideoMode=00000040
$C00C: PC=$BD77, VideoMode=00000040
$C00E: PC=$BD7A, VideoMode=00000040
$C000: PC=$BD7D, VideoMode=00000040
$C056: PC=$FB36, VideoMode=00000040
$C051: PC=$FB3C, VideoMode=00000040
$C000: PC=$0207, VideoMode=00000040
$C00C: PC=$BD77, VideoMode=00000040
$C00E: PC=$BD7A, VideoMode=00000040
$C000: PC=$BD7D, VideoMode=00000040
$C056: PC=$FB36, VideoMode=00000040
$C051: PC=$FB3C, VideoMode=00000040

$C052: PC=$24B9, VideoMode=00000040
$C057: PC=$24BC, VideoMode=00000044
$C050: PC=$24BF, VideoMode=00000004
$C00C: PC=$24C2, VideoMode=00000004
$C05E: PC=$24C5, VideoMode=00000006 ; 0000 0110 = HIRES|DHIRES
$C05F: PC=$24C8, VideoMode=00000004 ; 0000 0100 = HIRES
$C05E: PC=$24CB, VideoMode=00000006
$C05F: PC=$24CE, VideoMode=00000004
$C00D: PC=$24D1, VideoMode=00000005
$C05E: PC=$24D4, VideoMode=00000007 ; 0000 0111 = HIRES|DHIRES|80COL
$C051: PC=$24D7, VideoMode=00000047

$C001: PC=$CA9C, VideoMode=0000004F
$C000: PC=$CAB7, VideoMode=00000047
$C001: PC=$C81B, VideoMode=0000004F
$C00D: PC=$C81E, VideoMode=0000004F
$C00F: PC=$C821, VideoMode=0000004F
$C001: PC=$CD98, VideoMode=0000004F
$C000: PC=$CDBE, VideoMode=00000047
$C00C: PC=$CDC1, VideoMode=00000046
$C00E: PC=$CD8B, VideoMode=00000046
$C00C: PC=$1050, VideoMode=00000046
$C00F: PC=$1053, VideoMode=00000046
$C000: PC=$1056, VideoMode=00000046
$C001: PC=$CA9C, VideoMode=0000004E
$C000: PC=$CAB7, VideoMode=00000046
$C001: PC=$C81B, VideoMode=0000004E
$C00D: PC=$C81E, VideoMode=0000004F
$C00F: PC=$C821, VideoMode=0000004F

$C001: PC=$CE93, VideoMode=0000004F	; repeat 25 times
  :     :    :    :              :
$C001: PC=$CE93, VideoMode=0000004F

$C001: PC=$082C, VideoMode=0000004F
$C00C: PC=$0857, VideoMode=0000004E
$C05E: PC=$085A, VideoMode=0000004E ; 0100 1110 = TEXT|80STORE|HIRES|DHIRES
$C05F: PC=$085D, VideoMode=0000004C ; 0100 1100 = TEXT|80STORE|HIRES
$C05E: PC=$0860, VideoMode=0000004E
$C05F: PC=$0863, VideoMode=0000004C
$C00D: PC=$0866, VideoMode=0000004D
$C05E: PC=$0869, VideoMode=0000004F ; 0100 1110 = TEXT|80STORE|HIRES|DHIRES|80COL

$C001: PC=$4006, VideoMode=0000004F
$C057: PC=$C496, VideoMode=0000004F
$C052: PC=$C49C, VideoMode=0000004F
$C050: PC=$C49F, VideoMode=0000000F
$C051: PC=$C4E7, VideoMode=0000004F
$C056: PC=$C4EA, VideoMode=0000004B
$C05E: PC=$5E7E, VideoMode=0000004B ; 0100 1011 = TEXT|80STORE|DHIRES|80COL
$C00D: PC=$5E81, VideoMode=0000004B
$C057: PC=$5E8F, VideoMode=0000004F
$C052: PC=$5E8F, VideoMode=0000004F
$C050: PC=$5E8F, VideoMode=0000000F

The reason for the failure in AppleWin is this last access (at $5E7E) enables DHGR with HIRES off. The current AppleWin logic is: if HIRES is off then reset the DHGR mode, ie. use regular 140-color mode.

If I remove this logic then A2D enables 560 B&W mode as it should.

From the Video7 manual it says there is a video mode precondition... but given the "unusual" pre-video modes I've seen (eg. A2D and King's Quest), then I suspect that really there is no precondition.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

@inexorabletash / Joshua: thanks for your confirmation too.
I'll do a new build (this weekend?) removing the precondition logic I just described; and try to support HGR with color-burst disabled too.

@jvernet

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

About DHGR Mixed mode, I noticed that the white in 560x192 is not the same white in 240x192.
In 560x192, white is more grey than white.
You can only notice it when displaying pictures that have white in 2 resolution.
You can see it in this slide show: http://boutillon.free.fr/Underground/Anim_Et_Graph/Extasie_Chat_Mauve/Slides/Disks/dessins_crackman.do.gz, SATORI picture.

Is there any tools that can convert a PC picture to this mixed mode ?

@jvernet

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

Another curious behavior with this Slide Show
http://boutillon.free.fr/Underground/Anim_Et_Graph/Extasie_Chat_Mauve/Dsp_Img/Disks/Dsp_Img.dsk.gz (remove .gz at end, it's not a compressed archive).
Navigate to the IMG folder, display all images. Some will display in mixed mode, others in B&W mode. These are all Mixed Mode images (after Elephant).
See
image

image

I realy need to get back my Feline card to see on real hardware wich render is more accurate. Notice how some parts are'nt rendered the same way.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2019

re. the slide show

Each DHGR image is unpacked to $2000 (aux,main), then at PC=$8F93: bit7 of $2000 is tested:

  • bit7=1 means Mixed mode
  • bit7=0 means B&W mode

The value at (main memory) $2000 for "Pierre" (ie. the head coming through the computer) is 0x00, so DHGR get configured as B&W mode. (And the value at aux memory $2000 is also 0x00.)

NB. JACE does support the RGB modes: Mixed and B&W, so I don't know why this is working for JACE, but not AppleWin.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2019

About DHGR Mixed mode, I noticed that the white in 560x192 is not the same white in 240x192.
In 560x192, white is more grey than white.

OK, I see what you mean... in "50% Scan line" rendering, the B&W white has a very light grey between the white scan-lines. But the Mixed-mode white has black between the white scan-lines.

Try disabling "50% Scan lines" from the Configuration (or use CTRL+SHIFT+F9 to toggle).
Does this help?

Is there any tools that can convert a PC picture to this mixed mode ?

Not that I know of.
You could try asking on the comp.sys.apple2 mailing-list.

tomcw added a commit that referenced this issue Apr 6, 2019

Updates for DHGR MIX and B&W modes (#631):
. Relax the video-mode precondition to just checking VF_MIXED
. In DHGR B&W mode, then HGR screen is also B&W
. For '50% scan lines', don't blend in NTSC B&W mode (as this was inconsistent with the RGB colour rendering), and DHGR MIX mode would look odd!
@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2019

@jvernet : there's a new version of AppleWin 1.28.5.0 here:

  • (old) Apple II Desktop now works correctly (DHGR B&W mode is enabled)
  • then launching MousePaint, the HGR video will now be in B&W too (color burst continues to be disabled until you press RESET)
  • DHGR MIX mode ("Satori" picture): consistent white for Color and B&W modes

Outstanding is the "Pierre" image not enabling MIX mode.
Can you try this on real hardware?

@tomcw tomcw added the bug label Apr 6, 2019

@nicolho

This comment has been minimized.

Copy link

commented Apr 9, 2019

Hi ! First I should clarify that I've been thinking for a while about designing a simple but kind-of-standard RGB card for Apple II, with functionality similar to those Chat Mauve cards, and now I have good grasp of the hardware side of it, but no actual card at my disposal...

That's why I asked for help on a french forum and joined a recent discussion about jvernet's "Eve" card where he mentioned this ongoing implementation of mixed mode support in AppleWin. It looks like he still hasn't found the right card to provide the requested pictures, and in the meantime I got hold of the RGB adapter for Apple //c, still branded "Le Chat Mauve" but partly an Apple product too, with reference A2M4020F, and which I believe does the same thing that the "Féline" card (minus the 80 columns / memory extension).

Below are "out of camera" high resolutions photos of the Extasie slideshow on my Apple IIc. Sorry for the distorted geometry (close shots of this vintage Sony Trinitron monitor accentuates its curved screen, but I preferred it to my other CRT TVs since it has a finer pitch, thus less visible color artifacts from phosphors) and the slight blur, required to get rid of the unrealistic "moiré" effect, but with my entry-level camera and a ton of rejected shots, it was a close call between aspect accuracy and just enough pixel sharpness for your detailed inspection :
EXTASIE
ELEPHANT
TROMPE
EQUIPE
BRASIL
PIERRE
PORTRAIT
BOUTIQUE

(edit : except slightly different color tones, they all look pixel-wise identical to the pictures of this great comprehensive article in french about Extasie and its mixed mode that you could use instead of mine)

It looks like you almost nailed it, but there are still some small differences with your latest release (1.28.5.0). Now I must confess that I know little about of the software aspect (be it of Apple II graphics, or their emulation in Applewin) and I have no idea how it is consistent with the Apple RGB card, but here are some thoughts :
I've recently studied lesser known but similar RGB cards and schematics, whose digital logic follows the signal transitions of the "mixed mode" to either push the 14MHz pixels showed as-is in monochrome, or colors based on groups of 4 of those pixels (the 16 possible combinations correspond to NTSC color-carrier modulation patterns depicted in figure 8-11 of UTAII, and 8-10 of UTAIIe).

While this is obviously intended for LORES, it still applies in HGR and mixed mode since it seems that colors are always treated like this regardless of the graphic mode (sometimes resulting in inconvenient side effects, typically color artifacts occurring around white graphics that are a lot less subtle than in composite output).

A couple of days ago, while reading this thread, I decided to extensively check the available documentation to find a matching description aimed at developers, and there is one in this (massive) "Arlequin-Le Chat Mauve" manual ! : http://www.brutaldeluxe.fr/products/france/lechatmauve/lechatmauve_arlequin_manuel.pdf
I can translate this note of page 188 : "A color point is 4 times larger than a monochrome point. For users of the mixed mode, relations between coordinates in one mode and in the other can conveniently be found in those tables" in which you can see that every 28 DHGR pixel cell is composed of 7 "color points" (4 * 7 = 28).

In order to get a definitive answer, I intend to test this more extensively later, but I guess that, in the end, the pixels are "treated" by group of four (equivalent DHGR) pixels, and the color transitions are expected "modulo 4" like in those manual's tables, page 190 (and I wonder if video circuitry of the Apple II outputs them only at a quarter of the dot clock, which I suspect strongly but more Sather reading will be needed to confirm that).

I don't know if this is of any help (or identical on Apple IIe, even if it should) but thanks for your great work anyway ! Please let me know if there are other specific tests that I could do about this with the same setup in the coming days (I have some hi-def pictures of the other slideshow, Satori is exactly like in AppleWin, but some pictures present the same slight differences, I can post them if you want and if it is not too much).

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

Hi @nicolho,

Thanks for the info and real pictures!

I used the following .dsk image for the Extasie slide show, here. This one correctly displays "Pierre" image in MIX mode.

  1. If possible, can you try this image on your real //c...?
    http://boutillon.free.fr/Underground/Anim_Et_Graph/Extasie_Chat_Mauve/Dsp_Img/Disks/Dsp_Img.dsk.gz

As you can see, using AppleWin, some of the images are shown as B&W, not MIX mode.

  1. Re. this point:

It looks like you almost nailed it, but there are still some small differences with your latest release (1.28.5.0).

I see, eg.

  • "Elephant", in the bottom right, AppleWin has some thin, 1-pixel wide green vertical lines, but the real image has thicker, 4-pixel wide vertical lines.
  • "Pierre", AppleWin has a green/black vertical line between keys, but the real image just has grey.

Which as you say is explained by your translation of page 188.

@nicolho

This comment has been minimized.

Copy link

commented Apr 11, 2019

Hi Tom, my pleasure ! Just ask if you need more.

1) I tried the Dsp_Img.dsk floppy, and now I understand what is troubling you. Like in AppleWin, some pictures are correctly displayed, precisely : Elephant, Bastille, Trompe and Brasil.

But all the others are displayed in a non-alternating mode, like AppleWin does.... except that it shows them in "B/W DHGR" mode only, when I obtained the opposite on real hardware : all these pictures, including the IMG. prefixed monochrome drawings, are annoyingly stuck in color mode only, like this :

Dsp_Img_Pierre
Dsp_Img_Schema
Dsp_Img_Dieu_

I didn't try to compare the binary content of the image files , but when I open every picture of this floppy using the programs from Extasie Slideshow disk instead (DECOMP.BAS with UNPACK.BIN) they all show properly : Bastille, Schema and IMG.* pictures are B/W, and the others have a correct mixed-mode.

Looks like something is handled differently indeed, you can probably analyze what's going on in the software. Maybe it is working on Apple IIe ? We'll see what jvernet gets with it.
(I just noticed what could be a possible clue : for most of those that are showed correctly, like Elephant, Trompe and Brasil (but not Bastille?), their first pixel, at the top left, is a colored one... but maybe it's just a coincidence.)

About 2), you are twice right. For the grey tint, you can see the same defects in most of the slideshow images.
Now, even in the above examples (incorrectly) displayed in colors, you can more clearly see that every "color pixel" is necessarily "4 DHGR-pixel large" (and the same thing applies in HIRES or LORES).

As another example, take a look at this portion of the TROMPE image :

mixed_mode_comparison

The emulator in its current release shows many unnecessary shorter pixels. The original is simpler, the hills are drawn in a plain, single color, the flower petals on the right too, and their leaves are just two shades of green, and only their stems have black pixels...

One thing to consider is that this IIc adapter, with no access the CPU bus, doesn't have any hard or soft switch of its own, and the same applies to the Féline card (I studied the card's pictures and the memory extension is a distinct thing), almost all is handled by the motherboard's video circuitry of the Apple IIe or IIc.

As I tried to explain in my previous message, those "Le Chat Mauve adapters" (as the Arlequin's manual calls them) just treat the outputted 14M pixel stream, according to the provided /GR signal, thus either grouping them by 4 (to select color corresponding to the pattern) or passing them "as-is" in B/W (like for TEXT lines, or monochrome parts of a mixed-mode image).

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

(I just noticed what could be a possible clue : for most of those that are showed correctly, like Elephant, Trompe and Brasil (but not Bastille?), their first pixel, at the top left, is a colored one... but maybe it's just a coincidence.)

It's not a coincidence, this is how the code determines if the image is DHGR MIX or B&W.
I gave a few details further up this thread (test $2000's bit7).
Here's the code:

8F84:8D 08 C0             STA SETSTDZP   C008
8F87:8D 50 C0             STA SW.TXTCLR  C050
8F8A:8D 54 C0             STA SW.LOWSCR  C054
8F8D:8D 52 C0             STA SW.MIXCLR  C052
8F90:8D 57 C0             STA SW.HIRES   C057
8F93:AD 00 20             LDA $2000      2000
8F96:2A                   ROL                
8F97:90 21                BCC $8FBA          

; $2000.b7=1: DHGR MIX mode
8F99:8D 5D C0             STA CLRAN2     C05D	;  What's this for?
8F9C:8D 0C C0             STA CLR80COL   C00C
8F9F:8D 5E C0             STA SETAN3     C05E
8FA2:8D 5F C0             STA CLRAN3     C05F
8FA5:8D 0D C0             STA SET80COL   C00D
8FA8:8D 5E C0             STA SETAN3     C05E
8FAB:8D 5F C0             STA CLRAN3     C05F
8FAE:8D 5E C0             STA SETAN3     C05E
8FB1:A9 01                LDA #$01           
8FB3:8D 29 C0             STA $C029      C029	; IIGS: 0x01 => not SHR mode, b5=0 => Color
8FB6:8D 01 C0             STA SET80STORE C001
8FB9:60                   RTS                

; $2000.b7=0: DHGR B&W mode
8FBA:A2 02                LDX #$02           
8FBC:8D 01 C0             STA SET80STORE C001
8FBF:8D 5D C0             STA CLRAN2     C05D	;  What's this for?
8FC2:8D 0C C0             STA CLR80COL   C00C
8FC5:8D 5E C0             STA SETAN3     C05E
8FC8:8D 5F C0             STA CLRAN3     C05F
8FCB:8D 0D C0             STA SET80COL   C00D
8FCE:8D 5E C0             STA SETAN3     C05E
8FD1:CA                   DEX                
8FD2:D0 E8                BNE $8FBC          
8FD4:A9 21                LDA #$21           
8FD6:8D 29 C0             STA $C029      C029	; IIGS: 0x01 => not SHR mode, b5=1 => B&W
8FD9:60                   RTS                   

Any idea what the AN2 ($C05D) access is for?

NB. Dazzle Draw also accesses AN2 ($C05C). Here's the code to enable DHGR MIX mode:

6406:48                   PHA                
6407:A9 00                LDA #$00           
6409:8D 54 C0             STA SW.LOWSCR  C054
640C:8D 52 C0             STA SW.MIXCLR  C052
640F:8D 57 C0             STA SW.HIRES   C057
6412:8D 01 C0             STA SET80STORE C001
6415:8D 50 C0             STA SW.TXTCLR  C050
6418:8D 5C C0             STA SETAN2     C05C	;  What's this for?
641B:8D 0C C0             STA CLR80COL   C00C
641E:8D 5E C0             STA SETAN3     C05E
6421:8D 5F C0             STA CLRAN3     C05F
6424:8D 0D C0             STA SET80COL   C00D
6427:8D 5E C0             STA SETAN3     C05E
642A:8D 5F C0             STA CLRAN3     C05F
642D:8D 5E C0             STA SETAN3     C05E
6430:68                   PLA                
6431:60                   RTS                
@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

So my best guess is that this code tries to support all of these devices:

  • //e (Le Chat Mauve - card)
  • //c (Le Chat Mauve - RGB adapter cable)
  • IIGS (via $C029)
  • some other RGB card that uses AN2?

But it's not been well tested on all these machines (eg. perhaps only tested on IIGS?) and only half works.

I don't know why your "//c (Le Chat Mauve - RGB adapter cable)" is showing DHGR 140-pixel color mode, when AppleWin shows DHGR B&W mode. Perhaps again the code is not well tested, and there's subtle difference between the //e card and //c cable? Or AppleWin has a bug!

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2019

Outstanding is the "Pierre" image not enabling MIX mode.

I'm going to conclude that this is a bug in the DHGR setup code on the Dsp_Img.dsk.

Closing this issue as the original issues have been dealt with.
I have raised new issues to cover AN2 (#643) and improved DHGR 140-color rendering (#644).

@tomcw tomcw closed this Apr 14, 2019

@tomcw tomcw added this to the 1.28.5 milestone Apr 14, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2019

Hi @nicolho,

If possible could you also check these .dsk images too:

  • Dragon Wars (here): just boot to the title screen. Is it colour or B&W?
  • Renegade (here): how does the title screen look?

NB. The discussion about these 2 games is in #633.

Thanks.

@nicolho

This comment has been minimized.

Copy link

commented Apr 27, 2019

Hi Tom, so the results are the same than with AppleWin :

  • Dragon Wars's title screen is always B&W (looks like it is, like most DGHR games, intended to be seen in color on a NTSC display, but obviously unaware of any "DHGR 140 color mode" activation)

  • Renegade displays its DHGR title screen in color after a cold start, like this :

Renegade on Chat Mauve

...but not always ! 😕 and unlike AppleWin, after one reboot or more, it always shows up in B&W...

Sorry for my delayed response, I was intrigued and tried many things, but I haven't found any definitive "software" answer about it. And in this regard, my findings on //c could not be relevant with what happens with a real ][e...

(To know precisely how to deal with AN3 switching sequences will probably require a better understanding of the video circuitry and its digital logic's intricacies . Since I intend to dig more into it for my own research, I'll possibly report about it afterwards)

@tomcw tomcw referenced this issue Apr 28, 2019

Closed

DHGR in 1.28.x.0 #633

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2019

@nicolho - Moving discussion & my reply to #633.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.