The Quest for the Time-Bird
something worth noticing - amount of shades of gray:

Looking at the mode 4 palette, some of the colors have little difference in the two brightest levels. Perhaps there is excessive clamping at the upper end? The gradient of the mode 6 palette seems fine, though.

There are some odd transitions that extend into or past solid areas, creating seemingly detached hi-res edge details that stand out. Hard to describe, so I hope the blown-up pic makes clear what I'm referring to. This fringing behavior is not particular to the palette algorithm, as I also see it in the current composite rendering; however, it is more easily noticed when the gradient steps are less subtle. What is more strange is that the behavior only appears in certain places, not all. Just speculating, but maybe the averaging in the line drawing code is responsible.

the detached edges are also a reason for not clear letters on that yellow background in ms decathlon

NewRisingSun wrote:

For example, composite color 8 is almost always used as brown, on CGA composite and Apple II double hi-res alike, yet looks more like a yellowish green with standard NTSC. The only exception I have seen is the PC version of BurgerTime, which indeed uses it as a darker shade of green for lettuce.

Super Zaxxon has a lot of usage for shades. Red used as purple, yellow and brown as green.
White/orange, white/pink.
Blue/green and violet/blue look to be the least suitable here 😉

I can't make screenshots when COMPOSITE is On.

VileRancour didn't compiled with screenshots support so:
Alt-PrintScreen
Ctrl-V in PaintBrush

robertmo wrote:

Alt-PrintScreen
Ctrl-V in PaintBrush

Thank you for the advice.

Whys CTRL+F5 is disabled when Composite is on?

it doesn't work at all (not only in composite), because it takes to much time to figure out how to enable it when compiling

I think I pressed CTRL F6 unstead CTRL F5.

ripsaw8080 wrote:

Looking at the mode 4 palette, some of the colors have little difference in the two brightest levels. Perhaps there is excessive clamping at the upper end? The gradient of the mode 6 palette seems fine, though.

The same seems to happen with reenigne's original decoding method, and with the palettes provided by NewRisingSun (wikipedia, etc). I think it's just that mode 4 palettes inherently provide less distinct separation between similar color pairs than mode 6 does - you can see it in darker colors as well. This might explain why mode 6 with color burst (and grey/white pixels) was considered to be "the" composite color mode.
Of course, that could change if brightness and contrast adjustments were introduced, or even the plain color correction matrices discuessed so far.

There are some odd transitions that extend into or past solid areas, creating seemingly detached hi-res edge details that stand out. Hard to describe, so I hope the blown-up pic makes clear what I'm referring to. This fringing behavior is not particular to the palette algorithm, as I also see it in the current composite rendering; however, it is more easily noticed when the gradient steps are less subtle. What is more strange is that the behavior only appears in certain places, not all. Just speculating, but maybe the averaging in the line drawing code is responsible.

Looking at your zoomed-up image, these edge artifacts appear to be darker/brighter variations (Y) on their neighboring pixels - hue (I,Q) is always pretty much the same. I think these are a symptom of the insufficient number of palette entries: Y isn't constant across each consecutive group of 16 palette entries, while in mode 6/white it is.
This also causes the unreadable text in Decathlon: if you look at the characters closely, they're a big mess of shifted edge transitions.

By any chance, could you provide a build with screenshots enabled? win32 zlib and libpng are giving me a headache, but if I could look at the indexed png screenshots it might help me come up with a fix. Though I still think reenigne's proposed rewrite would be preferrable.

reenigne wrote:

Here's what happens on the 1501486:

Thanks for the explanation. A couple of questions:

1. What exactly is a HCLK and LCLK? I'm asking because I don't quite understand how this translates to high-resolution text mode, although I have read that it makes the color burst unusable.
2. Does that mean that the sync width register is completely ineffectual, because once HSYNC is raised, the shifting register/logic gate sequence runs through, overriding everything else?

reenigne wrote:

It fine-tunes the oscillator frequency:

Why does it need fine-tuning? Is the 14.38 MHz crystal so unstable?

reenigne wrote:

about 30ns or 40 degrees of hue shift

Does not look right at all though, in my opinion, both in mode 6 and in mode 4. King's Quest 1's title screen has a green background, and more importantly, the blue used in Ultima II's water tiles disappears almost completely. Obviously the artifact color/chroma color interaction is quite sensitive to this delay business, so it's important to get this right.

Either the 30 nanoseconds figure is too high, or we're incorrectly converting from nanoseconds to degrees hue shift. I use the following method: if one whole NTSC line is 63+5/9 microseconds long and has 455/2 subcarrier cycles, one subcarrier cycle is therefore (63+5/9 microseconds) / (455/2) = 0.279365 microseconds or 279.365 nanoseconds. 30 nanoseconds would therefore amount to (30 nanoseconds / 1000)/((63+5/9 microseconds)/(455/2))*360 degrees = 38.65909090... degrees, same as your result.

VileRancour wrote:

By any chance, could you provide a build with screenshots enabled? win32 zlib and libpng are giving me a headache, but if I could look at the indexed png screenshots it might help me come up with a fix.

Here's my recipe for getting DOSBox built with screenshots enabled:

Make two directories, one called zlib and one called libpng. Unzip the zlib sources into the first and the libpng sources into the other.
In zlib: do "cp win32/Makefile.gcc Makefile", "make" and "make install".
In libpng: do "cp scripts/makefile.gcc makefile", "make", "cp png.h pngconf.h /usr/local/include", "cp libpng.a /usr/local/lib", "cp scripts/pnglibconf.h.prebuilt /usr/local/include/pnglibconf.h", "export CPATH=/usr/local/include".
In the dosbox source directory, do a fresh "./configure" and watch for the 4 lines starting "checking png.h usability... yes" in the output (they should all be "yes"). Then rebuild.

VileRancour wrote:

I'm not sure if you're right about the cause though. Something I've noticed before, when poking around with GWBASIC in DOSBox: when I do the same thing and enter mode 4 ("SCREEN 1"), then do an "OUT &H3D8,&H1A", I get 640x200, but subsequent text output still produces double width (40-column) characters.

Ah, in that case perhaps Bruce Lee is using BIOS mode 6 and then tricking the BIOS into thinking it is in mode 4 by poking the appropriate value into the BIOS data area.

I'll get (physical hardware) screenshots of both Bruce Lee and Decathlon later.

Vile Rancour wrote:

could you provide a build with screenshots enabled?

Here you go. I've hooked up the new/old setting to an Alt-F10 keybind for testing.

NewRisingSun wrote:

What exactly is a HCLK and LCLK? I'm asking because I don't quite understand how this translates to high-resolution text mode, although I have read that it makes the color burst unusable.

HCLK is a 1.79MHz signal (the CRTC clock in 80-column text mode) and LCLK is a 895KHz signal (the CRTC clock in other modes). So the sync pulse timings are all the same in two modes except...

NewRisingSun wrote:

Does that mean that the sync width register is completely ineffectual, because once HSYNC is raised, the shifting register/logic gate sequence runs through, overriding everything else?

No, when +HSYNC DLY goes low the shift register U64/U43 is cleared and the +SYNC and +BURST lines go low, so the sync and burst are gated by the CRTC's HSYNC pulse. This explains why the 80-column BIOS text mode has no color burst - the HSYNC width is still 10 CRTC cycles, but they're now hchar width cycles instead of lchar width cycles, so the hsync pulse ends before the burst starts.

We might get some of the burst back by programming the CRTC to have a horizontal burst width of 15 (the maximum) but I think it will still be shorter than it's supposed to be. So setting the border colour to 6 is probably a better workaround as long as it doesn't make the rest of the screen too dark.

NewRisingSun wrote:

Why does it need fine-tuning? Is the 14.38 MHz crystal so unstable?

Apparently so, though only just: the color burst works fine over almost the entire range of the trimmer for me - there's just a small range over which the image goes black and white. Presumably the variance of these crystals (back then) was high enough that this trimmer was considered to be an important part of the crystal circuit.

reenigne wrote:

Either the 30 nanoseconds figure is too high,

Yeah, I think it's too high too. If instead of the "10ns for a gate, 30ns for a flip-flop" heuristic (which is probably aimed at the worst case) we take the average propagation delays from the datasheet (with 0 for the missing minimums) it goes down to 18ns or 23 degrees.

ripsaw8080 wrote:

Looking at the mode 4 palette, some of the colors have little difference in the two brightest levels. Perhaps there is excessive clamping at the upper end?

It's not excessive clamping - that's just the way the old CGA's composite generation works when the color burst is disabled: colours 1-6 become identical to 7 and colours 9-14 become identical to 15, so that text would not be legible with real hardware on a composite monitor either.

I think this is the main reason why the CGA hardware was revised - to make the shades of grey distinct for different colours on monochrome monitors.

reenigne wrote:

HCLK is a 1.79MHz signal (the CRTC clock in 80-column text mode) and LCLK is a 895KHz signal (the CRTC clock in other modes). So the sync pulse timings are all the same in two modes except...

So the character clock is always constant given a particular mode register setting? I had hoped that it forced LCLK when HSYNC is active. This complicates horizontal centering quite considerably... That would mean that with default BIOS-written timing register content, no mode is perfectly centered, but:

• all modes except 80 column text are shifted to the left: the complete active display area (characters/graphics plus overscan) is ($38+1-$0A)*16=752 pixels wide, similar to broadcast NTSC at 52+59/90 µs * 14.38 MHz=753.9318237304688 pixels. With default BIOS-written timing register content, there are ($38+1-$2D-$0A)*16=32 pixels of overscan to the left and ($2D-$28)*16=80 pixels to the right. More-or-less matches the MobyGames screenshots.
• 80 column text is more complicated, because the sync period is too short, as you mentioned: the complete active display area (characters/graphics plus overscan) is now ($71+1-$0A)*8=832 pixels wide, with ($71+1-$5A-$0A)*8=112 pixels of overscan to the left and ($5A-$50)*8=80 pixels to the right. Of course the 832 pixels do not really comprise a 4:3 image, so one could compromise by only taking the center 752 pixels from this, which would mean 112-(832-752)/2=72 pixels of overscan to the left and 80-(832-752)/2=40 pixels to the right. Oh boy.

reenigne wrote:

We might get some of the burst back by programming the CRTC to have a horizontal burst width of 15 (the maximum) but I think it will still be shorter than it's supposed to be.

I'll have to see what the Tandy 1000 does, which has proper color in 80 column text mode even with a black border. Either it sets the horizontal burst width to 15, or it selects LCLK for the 6845's CCLK input when HSYNC is raised, the latter seeming like the best possible solution to me (and something that IBM could easily have done for the CGA).

reenigne wrote:

it goes down to 18ns or 23 degrees.

Still too dark blues in mode 4, and violating every screenshot (taken with properly calibrated TV cards) I have seen in mode 6. It must be somewhere between 0 and 15 degrees. In the old composite mode thread from 2005 on this forum, Servo got (very slightly) different results from using the same card in different computers.

reenigne wrote:

If... we take the average propagation delays from the datasheet (with 0 for the missing minimums) it goes down to 18ns or 23 degrees.

Correcting for some arithmetic errors and using the correct type of flip-flop (74S series is faster than 74LS) gets us 14ns. Additionally taking into account that the pixel clock will be slower for red and green by 10ns adjusts that to 19ns, and taking into the account that the +I signal is actually faster than the color burst takes it to 12ns or about 15 degrees.

With a bit of work I could probably also adjust for the asymmetries between the high-to-low and low-to-high transitions - I'm not sure offhand whether that's likely to have a greater or lesser effect than other corrections that I don't know how to calculate.

reenigne wrote:

It's not excessive clamping - that's just the way the old CGA's composite generation works when the color burst is disabled: colours 1-6 become identical to 7 and colours 9-14 become identical to 15, so that text would not be legible with real hardware on a composite monitor either.

I'm having trouble correlating what you've written to the point I made. For one thing, I'm looking at mode 4, which means color burst is enabled; and for another, I haven't mentioned anything about text. Perhaps another picture will make things clearer. In the bottom two rows of the attached palette image, many of the colors have little difference and so don't have a luma gradient at the upper end. It's quite different from the smooth gradients in mode 6, and gives blockier fringes when there is no difference in those gradient steps.

I don't know enough to say it's wrong, I'm just making an observation; and it may indeed be alleviated, at least to some extent, with more luma levels in a larger palette.

NewRisingSun wrote:

80 column text is more complicated, because the sync period is too short, as you mentioned: the complete active display area (characters/graphics plus overscan) is now ($71+1-$0A)*8=832 pixels wide

That's not right - the width of the hsync pulse comes from the shift register (clocked with LCLK) not the CRTC, so it's always 4 lchars in both modes (modulo the hsync pulse getting truncated by 1 lchar, which I'm not sure about). So I think the centering will be the same in both modes (maybe 8 or 16 hdots left in 80-column mode - I'll see what my monitor does).

NewRisingSun wrote:

I'll have to see what the Tandy 1000 does, which has proper color in 80 column text mode even with a black border. Either it sets the horizontal burst width to 15, or it selects LCLK for the 6845's CCLK input when HSYNC is raised,

Or it doesn't gate the generated sync and burst pulse to the 6845's HSYNC pulse at all, and only uses its rising edge.

NewRisingSun wrote:

Still too dark blues in mode 4, and violating every screenshot (taken with properly calibrated TV cards) I have seen in mode 6. It must be somewhere between 0 and 15 degrees.

I didn't see that before my last message!

NewRisingSun wrote:

In the old composite mode thread from 2005 on this forum, Servo got (very slightly) different results from using the same card in different computers.

Weird! Maybe the +OSC duty cycle is different, or the +5V voltage.

reenigne wrote:

That's not right - the width of the hsync pulse

I'm talking about the CRTC's HSYNC signal, not the composite hsync pulse. So the centering calculations should be correct in theory, although I don't know how monitors and TV cards react to the unusually long non-sync period. I would suppose they just treat the "extra overscan" as blanking, so the "752 pixel compromise" I mentioned should be a good approximation of that. In any case, 80 column text should be shifted to the right, while all other modes should be shifted to the left. I could imagine that switching from black to color 6 in 80 column text mdoe would then shift the whole picture to the left as well on some monitors.

Terminology-wise, computer and video games are a nightmare, because the graphics device's "blanking" and "sync" don't correspond at all to composite video's "blanking" and "sync". 😀

reenigne wrote:

takes it to 12ns or about 15 degrees.

This would have the advantage of bringing yellow from 180 degrees close to the ideal 167.1 degrees. 😀 Of course, you no longer have a real red, more like magenta, but then again, the Apple II manuals also never mention a red, but only magenta. 😀 Decathlon with old CGA looks nice as well, although the blues in Ultima 2/3/4 are a bit dark, though not terribly so.

reenigne wrote:

Weird! Maybe the +OSC duty cycle is different, or the +5V voltage.

It was a 1501981 card put in a 5150 and a Tandy 1000, if I remember correctly.