RGB card decoder gets into weird states #850

xotmatrix · 2020-10-25T23:52:12Z

Start the Apple //e emulator with SL7 card -rgb-card-type sl7.
Configure video to RGB Card/Monitor
Boot Video-7 demo disk linked below.
Select 5 to load Video Modes demo.
Select demo 12 (16 color 160x192), looks normal, then select demo 13 (16 color 140x192), isn't decoded correctly.
Do step 1-4 above and select 13 first and then 12 isn't decoded correctly.
If 12 isn't decoded correctly, demo 11 (3 color 560x192) will also not be decoded correctly.

Selecting demo 14 (mix of 11 and 13) after 13 has glitched will also start glitched but restore the 140 decoder (13) the moment the 560 mixed text (11) is drawn. Variously ordered selections of demos 11, 12, 13 will eventually restore decoding of these different modes while glitching others.

Video-7 Apple II RGB Demo (Video-7, Inc.)(1984).dsk.zip

The text was updated successfully, but these errors were encountered:

fenarinarsa · 2020-10-26T15:35:51Z

How the extended DHIRES modes are actually triggered is not completely known. There is documented cases, but it looks like the hardware reacts to other cases. It's actually the same for the Applecolor RGB and Féline, and they all might have different hardware implementations - I hope not, since they were all made under Video-7's patent.

The best would be to test on a real SL7 card, but in the meantime I'm going to track the mode changes down to try to find a pattern and fix this.

Note: the Video-7 demo disk also have a different test menu for the IIc adapter which is triggered when running from a IIc. However you can run it manually from BASIC. The IIc adapters have the same features than the Féline card (no 160x192 mode), the only difference seems to be that the colors that aren't the same between the various adapters (analog/TTL/greyscale).

tomcw · 2020-10-26T17:40:12Z

@fenarinarsa - I took a quick look. At least for the "Extended 80-Column Text/AppleColor Adaptor Card", you can set the F2,F1 RGB mode just by toggling $C05E/5F, and without needing to touch $C00C/0D between each $C05E/5F toggle, eg, the following will set RGB 560 B&W mode:

$C00C
$C05E
$C05F
$C05E
$C05F
= RGB 560 B&W mode

(then $C00D & $C05E to set regular DHGR mode)

How about for your LCM adaptor?

fenarinarsa · 2020-10-27T00:40:15Z

It works but of course C00C/C00D needs to be written to.

*C00C:0
*C05E
*C05F
*C05E
*C05F
*C05E (re-enable DHIRES)
*C00D:0 (enable 80COL)

=> 560 BW

First thing first: except for the specific Video-7 modes, the demo disk runs perfectly on my IIc (I did RUN VIDEO MODES2E to avoid the specific IIc testing mode).

I did a lot (a lot!) of testing tonight on my LCM IIc adapter, and its behavior is... erratic to say the least.

It mostly seems to behave like the Video-7 patent describes it, that is, switching from $C05E to $C05F injects the current value of ~80COL to F1 (pushing F1 into F2). AN3 needs that specific change of state to inject ~80COL into the shift register, and that's how it's described in the patent (FIG1 with the two D flip flops).

However during my tests I found that sometimes, it didn't happen for some unknown reason. I did all my testing manually under the monitor and filled 3 sheets of results, and sometimes it doesn't work, and when I repeat all the sheet's pattern again, it works.

So I decided to make a test program consisting of 14 random opcodes patterns of C00C/C00D/C05E/C05F (each ending with C05E+C00D to enable DHIRES) and run it multiple times on my IIc, starting with 560 BW (F1=F2=1).

And then, I found out that I can't get to reproduce the exact same result at each run. Most of the code patterns generates the same modes at every run, but some don't. I even have cases where the first regular switch to 560BW didn't work. In AppleWin, the generated modes are always the same from one run to another.
I even added a VSYNC wait routine before each pattern, but it didn't change anything.

I don't know what to think about that... it looks like Pandora's box.

fenarinarsa · 2020-10-27T02:49:57Z

Okay, I made some progress.

First I removed all prerequisites in RGB_SetVideoMode(WORD address):

	// Clock in !80COL only when going from C05E to C05F
	if (address == 0x5F && g_rgbPrevAN3Addr == 0x5E)
	{
		g_rgbFlags = (g_rgbFlags << 1) & 3;
		g_rgbFlags |= ((g_uVideoMode & VF_80COL) ? 0 : 1);	// clock in !80COL
		g_rgbMode = g_rgbFlags;								// latch F2,F1
	}

	g_rgbPrevAN3Addr = address;

All video-7 DHIRES modes now work, except for the regular 140x192 mode... So I traced all video modes softswitches, and it appears that in 140x192, SW_IOUDIS is set to true so RGB_SetVideoMode() is never called from IOWrite_C05x()...

Note that I detected another bug in... HIRES modes. Test number 6 fails every other run.

For DHIRES here's the softswitches trace. (SW_IOUDIS) means that IO_Annunciator() is called instead of VideoSetMode().

160x192
Video switch: C050
Video switch: C052
Video switch: C057
Video switch: C00D
Video switch: C05E
Video switch: C05F
Video switch: C00C
Video switch: C05E
Video switch: C05F
Video switch: C00D
Video switch: C05E

140x192
Video switch: C050
Video switch: C052
Video switch: C057
Video switch: C00D
Video switch: C05E (SW_IOUDIS)
Video switch: C05F (SW_IOUDIS)
Video switch: C05E (SW_IOUDIS)
Video switch: C05F (SW_IOUDIS)
Video switch: C05E (SW_IOUDIS)

560x192
Video switch: C050
Video switch: C052
Video switch: C057
Video switch: C00C
Video switch: C05E
Video switch: C05F
Video switch: C05E
Video switch: C05F
Video switch: C00D
Video switch: C05E

Mixed
Video switch: C050
Video switch: C052
Video switch: C057
Video switch: C00D
Video switch: C05E (SW_IOUDIS)
Video switch: C05F (SW_IOUDIS)
Video switch: C05E (SW_IOUDIS)
Video switch: C05F (SW_IOUDIS)
Video switch: C05E (SW_IOUDIS)
(drawing)
Video switch: C050
Video switch: C052
Video switch: C057
Video switch: C00C
Video switch: C05E
Video switch: C05F
Video switch: C00D
Video switch: C05E
Video switch: C05F
Video switch: C05E

fenarinarsa · 2020-10-27T03:00:03Z

And BTW, I also traced how PoP initialize DHIRES:

Video switch: C051
Video switch: C00C
Video switch: C00D
Video switch: C057
Video switch: C05E
Video switch: C05F
Video switch: C05E
Video switch: C05F
Video switch: C05E

So it should be 140x192 in every case (C00D x2). Maybe it triggers a bug in LCM's IIc adapter? If that's the case, the first part of the intro being in color is pure chance.

Edit: do you believe it, I fixed the code of Prince of Persia and it's the $C057 that triggers the BW mode when the intro comes back to DHIRES! I really don't understand what's happening in the adapter. I wonder how the second part of the intro renders on other RGB cards. I don't think $C056/$C057 changes the state of ~80COL?

Original in UNPACK.S:

 sta ADCOLon
 bit HIRESon

 bit DHIRESon
 bit DHIRESoff
 bit DHIRESon
 bit DHIRESoff
 bit DHIRESon ;for old Apple RGB card

Fixed:

 bit HIRESon   <--
 sta ADCOLon   <--

 bit DHIRESon
 bit DHIRESoff
 bit DHIRESon
 bit DHIRESoff
 bit DHIRESon ;for old Apple RGB card

tomcw · 2020-10-27T13:33:44Z

Some thoughts:

IOUDIS ($C07E/7F) is //c only, not enhanced //e.
- The comment in AppleWin's Memory.cpp is wrong, and is derived from the "Apple //e Tech Reference Manual" (enhanced //e edition). It was probably a copy and paste bug from the //c TRM to the //e TRM!
- I need to fix AppleWin to not support IOUDIS for the enhanced //e model.
You are documenting some interesting behaviour for your LCM adaptor for //c... but we also need to test these "quirks" on other RGB cards, eg. Apple's and Video7's RGB cards.
- perhaps we should create a test .dsk, and ask the community to try it on real RGB cards?
Seeing as PoP's source code actually mentions "for old Apple RGB card", then my guess is that the switch to DHGR B&W (after the HGR Jaffar scene) is a quirk of LCM, and does actually work correctly on real Apple's RGB card.

fenarinarsa · 2020-10-27T15:33:18Z

  * The comment in AppleWin's Memory.cpp is wrong, and is derived from the "Apple //e Tech Reference Manual" (enhanced //e edition). It was probably a copy and paste bug from the //c TRM to the //e TRM!

Okay, I wondered why there was IOUDIS support :) anyway it works on my IIc so...? Well the bug is there anyway.

* You are documenting some interesting behaviour for your LCM adaptor for //c... but we also need to test these "quirks" on other RGB cards, eg. Apple's and Video7's RGB cards.

I already asked a friend to check on his LCM Eve (IIe).

* Seeing as PoP's source code actually mentions "for old Apple RGB card", then my guess is that the switch to DHGR B&W (after the HGR Jaffar scene) is a quirk of LCM, and does actually work correctly on real Apple's RGB card.

It might be. I took a look at the IIc's manual and Sather's book, and it might not be that trivial.
Actually, the 80COL signal that is triggered by the 80COL softswitch never makes it "as is" to the IIc adapter, which behaves as an extension of the 'IOU EXT VIDEO GEN" you can see in this IIe figure:

and it has only access to the following signals: 14M, VID7M, ~LDPS, TEXT, GR and SEGB.
Basically the 80COL switch changes the sync generation of VID7M and LDPS, and the adapter needs to "guess back" the status of 80COL based on that.
On the other hand, the AUX slot on a IIe has direct access to ~80COL.

So my guess is that it's a behavior of the IIc adapters only, and that you need to use the switchs in the correct order in that case to avoid messing with the signals' sync detection in the adapter.

tomcw · 2020-10-30T11:29:17Z

Hi @fenarinarsa,

I think a small patch (to remove the prerequisite checks, as in your code fragment above) is needed in the short-term to enable all the RGB DHIRES modes to be set correctly.

I'd be keen to push out a patch release of AppleWin with just this change so that anyone trying this new RGB video mode gets to experience the work you've done (and isn't confused by the current failing modes due to specific code sequences of C00C/D and C05E/F).

Then later, eg. when you get feedback from your friend on the LCM Eve for //e, we can refine the code appropriately.

Do you agree?

fenarinarsa · 2020-10-30T14:55:23Z

I got the test result of the LCM's Eve on a non-enhanced //e, PoP DHIRES screen shows in color with no bug at all. So my guess is the buggy behavior is specific to the IIc adapters - which ones, I'm not sure. As far as I know it may even be a defect of my adapter since I couldn't test any other.

For me it's better to push the patch as you say, and fix it later if we find other behaviors on //e. And ignore the //c adapters' instabilities completely.

. removed the precondition for enabling the extra RGB DHIRES modes . changed IOUDIS soft-switch so that it's for //c only

tomcw · 2020-11-02T20:23:58Z

@xotmatrix - try this new build AppleWin 1.29.16.0 - let us know how this goes.

xotmatrix · 2020-11-03T00:36:54Z

Looks good!

tomcw · 2020-11-05T20:45:42Z

Thanks for confirming. Closing.

xotmatrix mentioned this issue Oct 26, 2020

Default AppleColor RGB card is not working correctly. #851

Closed

tomcw added bug Peripheral labels Oct 27, 2020

tomcw added a commit that referenced this issue Oct 31, 2020

RGB card support: (#850)

fb08716

. removed the precondition for enabling the extra RGB DHIRES modes . changed IOUDIS soft-switch so that it's for //c only

tomcw added this to the 1.29.16 milestone Nov 1, 2020

tomcw closed this as completed Nov 5, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RGB card decoder gets into weird states #850

RGB card decoder gets into weird states #850

xotmatrix commented Oct 25, 2020 •

edited

Loading

fenarinarsa commented Oct 26, 2020

tomcw commented Oct 26, 2020

fenarinarsa commented Oct 27, 2020

fenarinarsa commented Oct 27, 2020

fenarinarsa commented Oct 27, 2020 •

edited

Loading

tomcw commented Oct 27, 2020

fenarinarsa commented Oct 27, 2020 •

edited

Loading

tomcw commented Oct 30, 2020

fenarinarsa commented Oct 30, 2020 •

edited

Loading

tomcw commented Nov 2, 2020

xotmatrix commented Nov 3, 2020

tomcw commented Nov 5, 2020

RGB card decoder gets into weird states #850

RGB card decoder gets into weird states #850

Comments

xotmatrix commented Oct 25, 2020 • edited Loading

fenarinarsa commented Oct 26, 2020

tomcw commented Oct 26, 2020

fenarinarsa commented Oct 27, 2020

fenarinarsa commented Oct 27, 2020

fenarinarsa commented Oct 27, 2020 • edited Loading

tomcw commented Oct 27, 2020

fenarinarsa commented Oct 27, 2020 • edited Loading

tomcw commented Oct 30, 2020

fenarinarsa commented Oct 30, 2020 • edited Loading

tomcw commented Nov 2, 2020

xotmatrix commented Nov 3, 2020

tomcw commented Nov 5, 2020

xotmatrix commented Oct 25, 2020 •

edited

Loading

fenarinarsa commented Oct 27, 2020 •

edited

Loading

fenarinarsa commented Oct 27, 2020 •

edited

Loading

fenarinarsa commented Oct 30, 2020 •

edited

Loading