Oh, it's been redumped at least twice by now, and even more-or-less commonly available. What is still needed is the non-Tandy version (i.e. just with Sierra on the title screen) and, more importantly, Oil's Well.
Hi,
So how come we can't get a utility that would enable the colorburst bit for CGA 640x200 mode and then remap the colors to Old/New/PCJR/Tandy color maps? I tried all of the utilities but none of them enabled the colorburst bit with a Sierra game running. 🙁
Chris
a utility that would enable the colorburst bit for CGA 640x200 mode and then remap the colors to Old/New/PCJR/Tandy color maps?
I don't understand what the request here is. Which game do you want to run on what hardware to yield what kind of display?
wrote:Never say never. 😉 I'm just starting to get interesting results from an idea I've had - watch this space...
...okay, two years later but I might as well drop this here...
I guess one has to emulate composite artifacting in text modes after all.
wrote:I guess one has to emulate composite artifacting in text modes after all.
I've attached a patch to do this. I have done very little testing on it so far, but it does seem to produce the correct colours in 80-column text mode. I've tuned the brightness and contrast so that black is 0,0,0 and white is 255,255,255 (so there is some clipping of colours) and tuned the saturation and default hue so that it matches a capture I made of the flower girl picture from 8088 MPH.
This patch uses the same algorithm I mentioned in my write up of the 8088 MPH 1K colour mode. It uses a 256-element table of values to describe the behavior of the chroma multiplexer chip on the CGA card. This eliminates the need for all the logic delay and chroma line phase stuff from my previous patch and gives more accurate colours as well. The table is derived from raw captures I made of my CGA card displaying some special calibration images I devised.
The emulation of a new-style CGA card is a bit of a guess based on the schematics and assuming that the chroma multiplexer is the same between the two cards (which it should be since the schematics for that part are identical). It should be reasonably accurate, but hasn't actually been calibrated against a real card.
This patch unfortunately doesn't do anything to improve composite emulation of Tandy 1000 or PCjr composite output. That's something I'd like to add but I don't have either of those machines to derive the multiplexer tables from. If anyone can help with that (either by sending me hardware or making captures of test images, ideally with a PCI capture card using a Brooktree 848 compatible chip like the Conexant Fusion 878A on the Hauppage ImpactVCB 00166 card I used for the CGA calibration) please let me know.
This patch does not do the Rec. 709 vs. NTSC 1953 primaries correction that was mentioned earlier in the thread. It could be added (at a slight runtime cost - 9 integer multiplies per pixel instead of 6) but I decided not to for a couple of reasons. The idea behind this correction is that if you connect a CGA card to a period (pre-1990) composite monitor that correctly implements the NTSC 1953 primaries and put it side by side with a modern sRGB (709 primaries) monitor running DOSBox and displaying the same source data, the images should look the same. That sounds like it would be ideal but has a couple of problems in practice. In particular, the white points are different between NTSC 1953 and Rec. 709 so if you display white on both monitors, it'll look redder on the older monitor. So if we implemented it in DOSBox then greys would look reddish compared to non-DOSBox windows and non-composite DOSBox windows running on the same monitor, which looks weird. Also, when this conversion is implemented it makes reds and oranges look unnaturally bright (much more "luminous" than greens and blues) which also looks weird. I redid the calculations myself and came up with the same matrix entries for the transformation so I think it's correct, it just doesn't look very good. Possibly more accurate to an "ideal" 80s composite monitor, but monitors varied so much in those days that Rec. 709 is probably at least as good an approximation of typical as NTSC 1953 (which is probably why it was picked for sRGB in the first place). Anyway, if you're interested in being colorimetrically-correct then DOSBox's composite CGA emulation is probably not the place for you: there are lots of other inconsistencies (variations between CGA cards, clipping, non-standard burst offsets/amplitudes and people adjusting their monitors to get a better picture) all of which add up to variations much greater than the differences between primaries. Yet another reason not to do the correction is that composite capture cards don't do it with their default software settings (at least the ones I've tried: Hauppage ImpactVCB 00166 and Pinnacle Dazzle DVC100).
Please replace every instance of "Rec. 601 primaries" in your post with "NTSC primaries" (or more accurately, 1953 NTSC primaries), because the Rec. 601 stuff is nonsense.
wrote:Please replace every instance of "Rec. 601 primaries" in your post with "NTSC primaries" (or more accurately, 1953 NTSC primaries), because the Rec. 601 stuff is nonsense.
Sorry for the confusion. You're right - I went back to check my calculations and it was indeed the NTSC 1953 primaries rather than the SMPTE C aka Rec. 601 primaries that gave the matrix we previously used. I've edited my post.
Bugs found so far: 1bpp graphics, 2bpp graphics and low-res text don't work properly, and the new CGA model is too dark. All should be easy to fix I think - expect the corrected patch tomorrow, along with a binary so that people who can't build DOSBox can do some testing.
wrote:Bugs found so far: 1bpp graphics, 2bpp graphics and low-res text don't work properly, and the new CGA model is too dark. All should be easy to fix I think - expect the corrected patch tomorrow, along with a binary so that people who can't build DOSBox can do some testing.
Here's the fixed patch and a binary build of it. If the binary complains about missing MSVCR120.DLL and/or MSVCP120.DLL you can get them by installing https://www.microsoft.com/en-us/download/deta … s.aspx?id=40784 .
The bright blue in King's Quest 1 CGA version is way too green at the default setting.
Also, I kind of expected a much sharper picture; in particular, the text seems much too rainbow-ish, even more so than the current DOSBox SVN. Compare the sharpness between the DOSBox build you just posted:
with my (non-DOSBox) decoder:
and Servo's (somewhat too dark and oversaturated) captured shot, captured from CGA installed in a Tandy 1000 (hence the different text artifacts):
wrote:The bright blue in King's Quest 1 CGA version is way too green at the default setting.
Yeah, I see what you mean. I think I need to tinker with the default hue some more. I tuned it to +9 based on an 80-column text screen, but differences in the colour burst between that mode and graphics modes may give a different hue offset, and it looks like -11 is more appropriate for 1bpp. I can always make the default hue different for different modes if necessary.
wrote:Also, I kind of expected a much sharper picture; in particular, the text seems much too rainbow-ish,
This is because the decoder I'm using separates luma from chroma using a bandpass filter rather than a notch filter, so loses all the 7.16MHz detail. My reasoning for doing that is that 7.16MHz detail is not particularly useful without 3.58MHz detail, but perhaps I'm wrong about that (and real monitors and capture devices do seem to preserve that detail). All the 7.16MHz detail should be present in the CGA simulation, and I think it should be not too difficult to tweak the decoder to display it. I will have a go at that this evening.
wrote:even more so than the current DOSBox SVN.
Are you sure about that? This is what the current SVN build looks like:
I can always make the default hue different for different modes if necessary.
I thought the whole point was to deduce everything from schematics, not by hand-tuning every individual mode. Didn't you calculate delays based on tracing schematics at one time?
Are you sure about that?
Yes, SVN is not any sharper, but the artifacts are just blue and red, not all over the (hue) place.
wrote:I thought the whole point was to deduce everything from schematics, not by hand-tuning every individual mode. Didn't you calculate delays based on tracing schematics at one time?
Schematics only got me so far, since the analogue behavior of digital electronics is not very well specified by the datasheets. This new implementation is based on measurements from real hardware and I believe it reproduces the composite signal generated by the CGA card very accurately. The difficult bit now is emulating the monitor (and what it will do with various non-compliant signals, in particular those with different color burst pulses). Fortunately there aren't so many parameter to hand-tune for that - currently I have modelled it with 4 (brightness, contrast, saturation and hue) and I'm about to add a fifth (sharpness), but I don't know of any way to deduce the best values for these parameters other than by hand-tuning (there are ideal values but they only work for compliant signals - with a real old CGA signal they give images which are extremely dark and totally unsuitable for DOSBox).
My current patch was tuned by looking at an 80-column text mode image in both DOSBox and on a real composite monitor connected to a real CGA card, and adjusting parameters until they look the same. However, the tunings for 80-column text mode don't seem to match those for 1bpp mode. The only reason I can think of for that is that the CGA card generates 6 cycles of burst pulse in 80-column mode and 8 cycles of burst pulse in 1bpp mode, and (on my monitor at least) that seems to result in a hue shift of about 20 degrees. Thinking about it, that does make some sense - I guess what happens is that the monitor is sensitive to a non-integer number of burst cycles in the period for which the burst is active for 1bpp mode and inactive in 80-column mode.
That suggests a way to model this which doesn't rely on mode-specific hacks - generate a simulated burst pulse in DOSBox the same way it happens in real hardware and then compute the burst phase from this looking at a set of samples which gives the correct hue in both modes (i.e. a 6th tuning parameter). That opens the door to emulating other behavior related to variation in burst pulses (like lack of colour in 80-column mode with the default border colour of black and the default hsync pulse width of 10 characters). Not that any games make use of that!
SVN is not any sharper, but the artifacts are just blue and red, not all over the (hue) place.
Yes, there is a bit more diversity in the colour of the fringes with my new patch - in particular, some fringes which looked bluish in SVN are more greenish with the new patch (even with hue set to -11). I think this is because I'm doing my chroma filtering with a smoother kernel ((1,4,7,8,7,4,1) in the new patch as upposed to (1,1,1,1) in SVN). This is also why the fringes in SVN look sharper and more saturated than those in my new patch.
Isn't it a matter of compromising/trading off, though? More pronounced, rainbow-like colored edges (with smoother filters), vs. vertical "ringing" artifacts around high-contrast edges (with sharper filtering - as seen in those non-DOSBox KQ shots)? At least, I'm unaware of anything that makes one more correct than the other.
Hue aside, this new patch produces a much better-looking image than current SVN, probably due to the smoother filtering - e.g. the castle bricks in the first game screen in KQ1 are a lot easier on the eyes now!
Isn't it a matter of compromising/trading off, though?
Not quite, because you can independently vary both luma and chroma bandwidths. The higher your assumed chroma bandwidth, the more bleeding from luma to chroma you get, and the worse your luma channel looks. DOSBox looks fuzzy because it has low luma and high chroma bandwidth, which is sort of the opposite of what you would want.
the castle bricks in the first game screen in KQ1 are a lot easier on the eyes now!
Apart from the hue shift, they look exactly the same to me.
Well, in current SVN the bricks have very blocky and prominent colored edges:
With the new patch (adjusted the hue somewhat), the edges are much less pronounced. You can see the improvement elsewhere, like the lack of spurious 1-pixel lines e.g. on Graham's cap:
wrote:All the 7.16MHz detail should be present in the CGA simulation, and I think it should be not too difficult to tweak the decoder to display it. I will have a go at that this evening.
Hmm... this turns out to be more difficult than I thought. When I generated the chroma multiplexer tables I didn't constrain the 7.16MHz component, so the tables ended up with non-zero 7.16MHz components even for pure colours. If I added that constraint I wouldn't have enough degrees of freedom (I'd essentially be forcing the sample position to be centered on the pixels instead of on the transitions, so it wouldn't capture any of the transition information). So I need to redo the calibration and simulation at double the sample rate.
How's this? Same CGA simulation as before (plus mode-dependent hue tweak) but instead of a (1,4,7,8,7,4,1) kernel I used a (1,1,1,1,1,1,1,1) kernel for chroma, subtracted the result from the composite signal and filtered the remainder with a (1,2,1) kernel for luma giving (I think) about 50% more luma bandwidth at the cost of halving the chroma bandwidth.
I tried leaving the 7.16MHz signal intact but the image becomes very stripy (alternating single-pixel columns of bright and dark pixels) due to me leaving this component unconstrained in the calibration program, as I mentioned yesterday. I am continuing to work on a version of the calibration program which leaves the 7.16MHz signal intact and therefore allows us to improve the sharpness further. However, doing so would inevitably introduce some stripiness. This is because the CGA card's output for a pure colour isn't a pure sine wave, and contains 7.16MHz components as well as 3.57MHz ones.
wrote:I tried leaving the 7.16MHz signal intact but the image becomes very stripy (alternating single-pixel columns of bright and dark pixels) due to me leaving this component unconstrained in the calibration program, as I mentioned yesterday.
Perhaps you could make this a user-configurable option? So the user can select whether to have the 7.16 MHz signal intact, or to filter it out?
The 'stripy' stuff looks wrong to me, since that is not what I see on a real NTSC display. But I can understand that in some cases people may prefer the 'sharper' look, despite the striping (which is what various capture devices also do, and possibly also some other digital displays, such as LCD/plasma TVs/monitors).
As for the above screenshot from the Tandy with the CGA card... Was that an old style or new style CGA card (was it even a real IBM at all?), since that would affect the colour appearance.
I haven't looked at your patch yet, but I assume you have included support for both types of CGA, and you tried to calibrate each routine against the real thing.
