Mental challenge: the rainbow

[Marc S. Ressl]

Hello everyone,

This code was posted by emphasis at comp.sys.apple2.programmer:

10 A = 9200
20 B = 13136 + 32
30 C = 100
40 TEXT : HOME
50 DATA 173,87,192,173,83,192,173,84,192,173,80,192,208,251
55 DATA 173,86,192,160,22,136,208,253,234,173,87,192,76,9,3
60 FOR I = 768 TO 796
70 READ N: POKE I,N
80 NEXT
100 HGR : POKE - 16302,0
110 HCOLOR= 4
120 HPLOT 0,0: CALL 62454
130 HCOLOR= 2
140 HPLOT 0,63 TO 279,63
150 HPLOT 0,62 TO 279,62
160 HCOLOR= 6
170 HPLOT 0,61 TO 279,61
180 HPLOT 0,60 TO 279,60
190 HCOLOR= 1
200 HPLOT 0,59 TO 279,59
210 HPLOT 0,58 TO 279,58
220 HCOLOR= 5
230 HPLOT 0,55 TO 279,55
240 HPLOT 0,54 TO 279,54
250 HCOLOR= 0
260 HPLOT 0,123 TO C,123
261 HPLOT 0,122 TO C,122
262 HPLOT 0,119 TO C,119
263 HPLOT 0,118 TO C,118
270 COLOR= 0
280 FOR I = 0 TO 39
290 VLIN 0,39 AT I
300 NEXT
310 COLOR= 13
320 HLIN 0,39 AT 14
330 FOR I = 0 TO 7
340 POKE A + I,0
345 POKE B + I,0
350 NEXT
360 COLOR= 1
370 HLIN 0,39 AT 13
380 VTAB 21
390 PRINT TAB( 16)"RAINBOW"
400 PRINT : PRINT "MIXED GRAPHICS (HI-RES/COLOR)"
500 CALL 768

I've re-factorized the timing code in OpenEmulator, and the rainbow is
showing. My problem is the "special" lines are flickering at the
beginning.

I have checked the code, and it seems it should be flickering (the
loop waits for a non-zero byte on the floating bus), but could
somebody with a real Apple II or II plus check?

Thanks a lot,

Marc.-

[mmphosis]

On Feb 5, 7:25 pm, "Marc S. Ressl" <mre...@gmail.com> wrote:
> Hello everyone,
>

> This code was posted by mmphosis at comp.sys.apple2.programmer:

From memory, a long long time ago, when I ran this on a real Apple II
plus, it would *usually* (emphasis on usually) display the rainbow
without any flickering. But, I think that sometimes, if my memory
serves me, it would flicker. It could be a timing thing: The code
waits for a non-zero byte on the floating bus and it can only catch a
byte every amount of cycles that the loop takes to iterate. The
positioning of those zero bytes is critical. Maybe, sometimes it
misses depending on what byte it starts reading the floating bus at,
whereas *usually* (mmphosis on usually) it starts reading at a byte
where everything aligns and the rainbow appears without flickering.

mmphosis

[Marc S. Ressl]

Hello mmphosis:

thanks a lot for your response! I am very intrigued by this test, as
it seems excellent for testing emulators. So I went through it...

As to the BASIC part:

* BASIC Lines 110-120 fill $2000-$3FFF with $80
* BASIC Lines 130-240 draw the HIRES color lines 54-55, 58-59, 60-61,
62-63
* BASIC Lines 250-263 fill lines 118, 119, 122 and 123 with color 0
for X = 0 to 100 (this hides the delayed extensions of lines 54-63)
* BASIC Lines 330-350 fill $23F0-$23F7 and $3370-$3377 with $00 (this
is the important stuff)

* BASIC Lines 270-300 clear the text screen to $00
* BASIC Lines 360-380 draw the LORES line at Y=13 (HIRES lines 52-55)
* BASIC Lines 310-320 draw the LORES line at Y=14 (HIRES lines 56-59)

As to the assembly part:

0300- AD 57 C0 LDA $C057 // set HIRES
0303- AD 53 C0 LDA $C053 // set MIXED
0306- AD 54 C0 LDA $C054 // clear PAGE2

0309- AD 50 C0 LDA $C050 // read /TEXT, 4 cycles
030C- D0 FB BNE $0309 // 3 cycles
030E- AD 56 C0 LDA $C056 // set LORES, 4 cycles
0311- A0 16 LDY #$16 // 2 cycles
0313- 88 DEY // 2 cycles
0314- D0 FD BNE $0313 // 3 cycles
0316- EA NOP // 2 cycles
0317- AD 57 C0 LDA $C057 // set HIRES, 4 cycles
031A- 4C 09 03 JMP $0309 // 3 cycles

The first loop searches for a zero value while scanning HIRES. This
happens on several occasions, but most importantly just before lines
51 and 55 (because of horizontal blanking).

When the first loop exits, LORES is switched on for 4+2+5*22+2 = 118
CPU cycles. This happens to be almost two scan lines (each scan line
has 65 CPU cycles).

I must confess this is pretty clever, and it also seems my emulator
has a bug :-).

With the best wishes,

Marc.-

[Marc S. Ressl]

Hallelujah! I fixed it.

It happens the actual video rendering was 9 cycles behind the floating
bus timing. Now things match, and the test looks beautifully ;-).

With the best wishes!

Marc.-

[Antoine Vignau]

Congratulions, Marc,
A really good news,
antoine

[Marc S. Ressl]

On 8 feb, 23:39, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> Congratulions, Marc,
> A really good news,
> antoine

For your viewing pleasure:

http://openemulator.googlecode.com/files/rainbow2.png

;-D

[BLuRry]

Awesome! Glad to know this is possible! :-D Thanks Marc!

[D Finnigan]

Marc S. Ressl wrote:
> On 8 feb, 23:39, Antoine Vignau <antoine.vig...@laposte.net> wrote:
>> Congratulions, Marc,
>> A really good news,
>> antoine
>
> For your viewing pleasure:
>
> http://openemulator.googlecode.com/files/rainbow2.png
>
> ;-D
>

Perfect. That matches my photo that I took last evening:

http://macgui.com/gallery/showphoto.php?pic_id=1539

--
]DF$
Mac GUI Vault - A source for retro Apple II and
Macintosh computing.
http://macgui.com/vault/

[Marc S. Ressl]

Thanks a lot for posting that photo.

Now something else caught my attention. It seems the text colors do
not match. It should be cyan and orange, not green and violet.
Argh :-).

[Antoine Vignau]

I hate the virtual keyboard of the ipad!
and I like the photos of yours, Gentlemen,
antoine

[D Finnigan]

Those colors are peculiar to my model of Apple II Plus, and perhaps to the
television set.

I wouldn't worry about it. I noticed that I could adjust the trim pot to
change the color hues, but I haven't spent any time doing so.

The same screen (Choplifter, for example) when shown on that same TV set has
different colors depending on if I have the Apple IIe plugged in, or if I
have the Apple II Plus plugged in.

[Linards Ticmanis]

On 02/09/2012 07:59 PM, Marc S. Ressl wrote:

> Now something else caught my attention. It seems the text colors do
> not match. It should be cyan and orange, not green and violet.

The text fringing is always green and violet in mixed mode on my NTSC
Apples. The PAL ones have no fringes on the text (they have a shaky
picture instead ;-)

--
Linards Ticmanis

[D Finnigan]

Linards Ticmanis wrote:
> On 02/09/2012 07:59 PM, Marc S. Ressl wrote:
>
>> Now something else caught my attention. It seems the text colors do
>> not match. It should be cyan and orange, not green and violet.
>
> The text fringing is always green and violet in mixed mode on my NTSC
> Apples.

Right. I believe that the discrepancy is due to the color trim pot on my
Apple II Plus.

[Marc S. Ressl]

> Macintosh computing.http://macgui.com/vault/

Thanks a lot for the good news. :-)

Another question... on PAL Apple II's, full-screen text is displayed
in white (as is the case for NTSC, because there is no color carrier).
But is that also true in mixed mode? In NTSC it is, because the color
carrier is turned on.

[Vladimir Ivanov]

On Thu, 9 Feb 2012, Marc S. Ressl wrote:

> Another question... on PAL Apple II's, full-screen text is displayed
> in white (as is the case for NTSC, because there is no color carrier).
> But is that also true in mixed mode? In NTSC it is, because the color
> carrier is turned on.

As we have discussed some time ago with M.J. Mahon, even if some lines
don't have color carrier, they will still be displayed in color. It's
because of the way TV's color carrier detector works - it has LPF for
stability. If you feel lucky with searching you might find Michael's
estimate of the time constant.

[Linards Ticmanis]

On 02/09/2012 11:00 PM, Marc S. Ressl wrote:

> Another question... on PAL Apple II's, full-screen text is displayed
> in white (as is the case for NTSC, because there is no color carrier).
> But is that also true in mixed mode? In NTSC it is, because the color
> carrier is turned on.

Unlike NTSC Apples, PAL machines use two separate quartz oscillators for
the dot clock and the color clock. This prevents the color fringing in
mixed mode since the letter elements aren't output at a multiple of the
color carrier frequency.

On the downside, the presence of two independent quartzes gets you a
"beat frequency" which changes with the exact tuning of the quartzes (so
it goes up and down with heat etc.), this causes ugly moving moiré
patterns in graphics mode.

--
Linards Ticmanis

[BLuRry]

Is it possible to sync with VBL such that during VBL, and during the majority of each HBL the apple is put in a text mode but during active signal output throw it back to graphics? That should fake out the apple to not send a color bust, right? Would be interesting to get a grayscale mode... really just for kicks if nothing else.

[BLuRry]

err... I meant color BURST. But I guess you can mockingly call it "color bust" in this case to honor of my unfortunate typo. ;)

[Michael J. Mahon]

BLuRry wrote:
> Is it possible to sync with VBL such that during VBL, and during the majority of each HBL the apple is put in a text mode but during active signal output throw it back to graphics? That should fake out the apple to not send a color bust, right? Would be interesting to get a grayscale mode... really just for kicks if nothing else.

As Vlad recently noted, NTSC monitors do not switch instantly from color
to monochrome and back.

To allow for color reception under marginal signal conditions, the mode
switching typically occurs over several frame times, and is a precise
standard, so this switching 1) cannot be done quickly, and 2) cannot
be done with reliable results for various monitors.

Typically, switching from monochrome to color occurs more quickly than
switching back from color to monochrome, but both time constants are
long relative to intra-frame times.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

[Marc S. Ressl]

Hello everyone:

this opens yet another issue I wasn't aware of... in my emulation I do
consider the color carrier, and you can even specify color carrier
phases for every line :-).

But the choice of color or monochrome is based upon sampling the color
carrier at the beginning of the frame. Do you consider that
appropriate?

For example, in the split screen code of the "Test: the cycle" thread,
color is shown depending on whether there was color carrier at the
beginning of the frame or not...

[Linards Ticmanis]

On 02/10/2012 04:21 PM, BLuRry wrote:
> Is it possible to sync with VBL such that during VBL, and during the majority of each HBL the apple is put in a text mode but during active signal output throw it back to graphics? That should fake out the apple to not send a color bust, right? Would be interesting to get a grayscale mode... really just for kicks if nothing else.

To see the effect, just write some simple loop that takes exactly 64
cycles and repeatedly switches back and forth between graphics and text.
If you just start it by hand several times, you'll get color in some
cases and no color in others, depending on whether graphics are active
or not during the color burst phase of each line.

The problem with this is that it's hard to do anything else at the same
time. You can stop the switching (stay in text mode, do your processing)
during VBL, but I assume it's difficult to get back up again at the end
of VBL at the right moment, unless your whole processing code is also
cycle counted.

If you have a cyclical interrupt source such as a Mockingboard or other
MOS6522 card available, it would help with restarting the switching in
time. First you'd have to perfectly align the 6522 with the video
scanner. That takes some tricky code, testing the VBL condition (via
vaporlock techniques, or directly on the //e and above) on several
consecutive frames and shifting the alignment up or down as necessary,
since you can't test it every cycle. AFAIK it can be done with three
frame times of testing, if you get it right.

After this, then the Mockingboard would interrupt the CPU on exactly the
same, known spot in every frame, shortly before the end of VBL. But
you'd still end up some cycles off, since interrupts on the 6502 family
don't interrupt within instructions, only in between them. I guess you
could read the re-started counter from the 6522 and use the value you
read to go down six different code paths (I think six is the highest
number of cycles any 6502 instruction takes, right?), each of them
taking one cycle longer than the one before, then re-converging. That
way you could shift your switching code back and forth so that it aligns
in lock-step with the color burst generation. The whole process is
similar to the FLI and IFLI modes used in some of the later C64 stuff.
Also similar in spirit to ZX81 or Atari 2600 programming.

Oh, and no, I've never written such a program.

--
Linards Ticmanis

[D Finnigan]

Linards Ticmanis wrote:
>
> read to go down six different code paths (I think six is the highest
> number of cycles any 6502 instruction takes, right?),

BRK, and some instructions using abs,X addressing will take 7 cycles.

[Antoine Vignau]

6502.org is your friend: http://www.6502.org/
av

[Vladimir Ivanov]

On Fri, 10 Feb 2012, Marc S. Ressl wrote:

> But the choice of color or monochrome is based upon sampling the color
> carrier at the beginning of the frame. Do you consider that
> appropriate?

Yes, you still check for burst on each line.

Which you filter, and the filtered result is what actually drives the
render. Try with Michael's suggested time constant of few frames.

[Marc S. Ressl]

On 10 feb, 19:55, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote:
> On Fri, 10 Feb 2012, Marc S. Ressl wrote:

> > But the choice of color or monochrome is based upon sampling thecolor> carrierat the beginning of the frame. Do you consider that

> > appropriate?
>
> Yes, you still check for burst on each line.
>
> Which you filter, and the filtered result is what actually drives the
> render. Try with Michael's suggested time constant of few frames.

Thanks a lot for the comments. Would somebody be so nice as to refer
me to Michael's post on color carrier detection? I can't seem to find
it :-(.

With the best wishes,

Marc.-

pd: did real monitors detect and enable color carrier recovery only at
the beginning of a frame, or is there a chance the detector toggles in
the middle of a scan line? Now this is a really nerdy question!! :D

[Vladimir Ivanov]

On Fri, 10 Feb 2012, Marc S. Ressl wrote:

> On 10 feb, 19:55, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote:
>
>> On Fri, 10 Feb 2012, Marc S. Ressl wrote:
>
>>> But the choice of color or monochrome is based upon sampling thecolor>
>>> carrierat the beginning of the frame. Do you consider that
>>> appropriate?
>>
>> Yes, you still check for burst on each line.

Little note here - I meant that appropriate is sampling the burst presence
on each line, not on each frame.

>> Which you filter, and the filtered result is what actually drives the
>> render. Try with Michael's suggested time constant of few frames.
>
> Thanks a lot for the comments. Would somebody be so nice as to refer
> me to Michael's post on color carrier detection? I can't seem to find
> it :-(.

Me neither. Google is not about searching anymore?

> pd: did real monitors detect and enable color carrier recovery only at
> the beginning of a frame, or is there a chance the detector toggles in
> the middle of a scan line?

The monitors we're talking about, being simple analog devices, most likely
switch whenever the color burst detector filter commands - so, yes,
anywhere, including in the middle of a scan line. And because then the
color PLL is not locked you will get off colors for few lines until it
locks.

What I suggested to you is:
1) sample each line's color burst presence
2) filter it via simple filter, time constant few frames
3) render each line monochrome or color depending on filter output

Don't waste too much time over this, Marc. :-)

[Michael J. Mahon]

I agree--this is probably not too important, for the simple reason
that color killer switching time (filtering) was never standardized,
but was an engineering choice usually made for pragmatic reasons,
like acceptable performance and low cost.

In the early years of color TV in the US, color programming was
mostly limited to network shows, with most local programming and
commercials remaining in black and white. As a result, the color
killer was exercised often, with 30-second local B&W spots inserted
into network shows during commercial breaks.

With frequent switches, it was desirable to make the transition as
quickly and glitch-free as possible without incurring false triggering
due to short signal dropouts. The lower limit on switching delay
was set by the time that the color reference PLL took to lock to
the color burst stream, usually a good fraction of a frame time.

In the interest of keeping costs low, very simple low-pass filtering
was used on the instantaneous "burst detected" pulses to create the
"enable color" signal. Typically it was simply an RC filter with a
time constant on the order of a frame or two (1/30-1/15 second).

The long-standing "tradition" of going to black for several frames
between signal source switches served to mask any spurious color
or monochrome intervals, as well as masking any sync disruptions
when switching local-to-network or network-to-local.

This RC (1-pole) filter can be easily implemented as an exponential
average of the line-by-line "burst detected" signal to create the
"enable color" signal, which is then thresholded to do the mode
switch. For example, during each line processing:

enable_color = (1-1/color_time_constant)*enable_color
+(1/color_time_constant)*burst_detected;
color_mode = enable_color > .5;

Where burst_detected is either 0 or 1 and color_time_constant
is the approximate switching time constant in line times--for
example, 500.

In principle, once the color reference PLL has synchronized, it
would be possible to switch off the burst for short periods
without losing lock, and, if this were promptly detected, individual
lines could be rendered in monochrome. However, frequent resumptions
of the burst signal would always be required to maintain color lock.

[Alex Freed]

On 2/11/2012 1:35 AM, Vladimir Ivanov wrote:
> yes, anywhere, including in the middle of a scan line. And because then
> the color PLL is not locked you will get off colors for few lines until
> it locks.

Actually in most cases the PLL locking on the color burst is exactly
what turns the color on.

The circuit is quite simple: a phase detector is fed with the burst and
the local oscillator shifted by 90 degrees. If there is no lock, the
output will change polarity and average to zero. After the oscillator
locks, there is a a full signal of one polarity whenever there is a
burst present. This voltage is filtered and becomes the color enable.

-Alex.

[Vladimir Ivanov]

Hi Alex,

Well, in this case the PLL is already locked, so no rainbows. :-)

The color enable will still trigger somewhere when the filter output
passes certain threshold, so I guess it's safe to assume it can be
mid-line.

Not that it matters at all at 60 Hz.