HunterZ wrote:

Is this different from what non-patched SVN does? Because scaling works fine there.

Note that the only scaling that I prefer to use is what you get with aspect=true plus output=opengl. I usually use scaler=none.

Ah, okay, "scaling" threw me off there. 😉 With scaler=none there should be no difference; it's normal2x/3x that are enabled for double-width/height modes.

Perhaps the different behavior in your case is due to the higher bit-depth surface in the newest composite patch... guess some output methods may have a hard time filtering/scaling it. I don't have the problems you describe with opengl though, so it may be a driver settings thing.

Just curious. I finally got my bootable img of Seven Cities Of Gold (original 1980s version and not the Commemorative Editon from 1993) working in DOSBox SVN r4000 in composite mode and it looks and plays great. I was wondering, though, if anything came of trying to run composite games in the PCjr machine mode? The reason I ask is Seven Cities Of Gold used the enhanced sound of the PCjr and it would be amazing if you could get composite mode colors with the PCjr enhanced sound combined. Not a biggie as I am super happy to get the original game working in composite mode to begin with. Thanks.

Patch for PCjr composite support, tested with

• Ultima II (special PCjr version)
  The attachment U2jr.png is no longer available
• B.C.'s Quest for Tires
  The attachment BC.png is no longer available
• The Seven Cities of Gold
  The attachment 7cities.png is no longer available

NewRisingSun wrote:

I'd like to update the reengine patch as well for its higher artifacting quality, but I don't have the slightest clue what that chroma_multiplexer array thing is. I understand that "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.", but it's entirely intransparent what these 256 values exactly mean.

The array element [x*32 + y*4 + z] corresponds to the part of the transition from colour x to colour y (lowest 3 bits of each colour only - the intensity bit is handled separately) at phase z (0 to 3) within the colour carrier cycle. So the samples we get out of this are shifted horizontally slightly from the RGBI pixel grid (this can be compensated for in the decoder if you like, but it doesn't really matter).

Ideally these values should be sampled from hardware in order to capture the full range of behaviour of the multiplexer. I'd like to do this for PCjr and Tandy as well, but I don't have either of those machines yet. Somebody else could do it if they have a capture card that could capture raw samples (ideally a Hauppage ImpactVCB or another card with a Brooktree 848 compatible chip like a Conexant Fusion 878A).

NewRisingSun wrote:

Patch for PCjr composite support, tested with...

Wow! Nice! The PCjr sound is so much better in SCOG and now with composite enabled this is great! One difference I noticed is the PCjr machine mode composite has more color saturation. Thanks for the file!

NewRisingSun wrote:

Patch for PCjr composite support, tested with... The Seven Cities of Gold

Just noticed where light blue should be, magenta has taken its place. Is this the emulation or the way the PCjr machine type behaves? Wondering if that can be corrected somehow? If you look at my previous post of the harbor screenshots you see the original r4000 text "MAR. - 1492" with magenta artifacts and in this post the map screen has light blue water. In the PCjr composite harbor scene the text artifacts are light blue and the map screen has magenta water. Its like the two colors got reversed. I have no idea, just thought I would ask. Appreciate the effort.

The game still seems to be in 640x200 composite mode, so all colors are entirely determined by the particular black and white pixel patterns that the game uses. There is little that the emulation can do about that --- if one modified the pixel clock delay to make that magenta look blue, everything else would look wrong. You will find that other games have even worse differences between CGA Composite and PCjr composite. Below the Root comes to mind.

reengine wrote:

Ideally these values should be sampled from hardware in order to capture the full range of behaviour of the multiplexer.

The approach seems efficient coding-wise, but does nothing to document what the multiplexer actually does; it basically remains a black box. Ideally, one would emulate every aspect of the multiplexer while keeping the efficiency by initially calculating that array's content at run-time in VGA_SetupOther, or defining its content using macros. I assume that some finer aspects may still be unknown however, and that this approach allows one to have accurate emulation without understanding every last detail?

reengine wrote:

within the colour carrier cycle.

Does the multiplexer behave differently at different stages of the color carrier cycle, or does that array then incorporate a part of the NTSC demodulation?

NewRisingSun wrote:

The game still seems to be in 640x200 composite mode, so all colors are entirely determined by the particular black and white pixel patterns that the game uses. There is little that the emulation can do about that --- if one modified the pixel clock delay to make that magenta look blue, everything else would look wrong. You will find that other games have even worse differences between CGA Composite and PCjr composite. Below the Root comes to mind.

I figured it was a Pandora's box. Fully appreciate your explanation and thanks for the file and your time on this. It really is amazing how far DOS emulation has come over the years. The fact we can even get to see these composite modes again in emulation is outstanding. Reliving my childhood currently playing "ICON: Quest for the Ring". A game that achieved 16 color graphics in a unique text mode. (which I originally thought was a composite mode)

NewRisingSun wrote:

reengine wrote:

Ideally these values should be sampled from hardware in order to capture the full range of behaviour of the multiplexer.

The approach seems efficient coding-wise, but does nothing to document what the multiplexer actually does; it basically remains a black box. Ideally, one would emulate every aspect of the multiplexer while keeping the efficiency by initially calculating that array's content at run-time in VGA_SetupOther,

Essentially that was what I tried to do with the implementation I had before this one. However, I wasn't able to come up with an algorithm that generated correct colours in all modes. I modelled the CGA composite output stages in greater and greater detail, with more and more logic delays and more and more tuning knobs to adjust, with increasingly complex hill-climbing algorithms to optimize these knobs to match captured data, but it was still far from being accurate. Then I came up with this method which has a very large number of tuning knobs but is otherwise extremely simple and easy to optimize.

NewRisingSun wrote:

I assume that some finer aspects may still be unknown however, and that this approach allows one to have accurate emulation without understanding every last detail?

Exactly.

NewRisingSun wrote:

reengine wrote:

within the colour carrier cycle.

Does the multiplexer behave differently at different stages of the color carrier cycle, or does that array then incorporate a part of the NTSC demodulation?

The multiplexer itself doesn't behave differently, but the array also incorporates the 8 "direct colour" inputs to the multiplexer, 6 of which have a 3.57MHz component. I suppose it may be possible to model them separately by probing those lines on the card and making some very high resolution measurements, but I'm not sure there's any advantage in doing so. Fundamentally, the multiplexer itself is still a black box. And doing it this way would not even necessarily help PCjr/Tandy emulation very much since they use different multiplexers (implemented in a ULA instead of a discrete 74LS151).

Point me to a currently-available card that has that kind of chip, and I will purchase one and sample the values from my Tandy 1000 TX.

NewRisingSun wrote:

Point me to a currently-available card that has that kind of chip, and I will purchase one and sample the values from my Tandy 1000 TX.

The ImpactVCB is an old (PCI) card but it does still seem to be available from several suppliers. I think the 00558 or 00166 models would be most likely to work (I have an 00166 which is a low profile card but I just removed the metal part to fit it in my machine). I think https://www.amazon.co.uk/Hauppauge-Impact-Com … te+capture+card is the 00558 if you select the PCI version. There is also http://www.ebay.co.uk/itm/Hauppauge-ImpactVCB … aUAAOSwPCVX47Hg which looks like a bargain.

We'll also need a program to run on the machines to generate test images with as many left-colour/right-colour/phase combinations as possible - I don't think the one I made for CGA will work on PCjr or Tandy. I'll have a go at writing one if you like, but it might take a few iterations to get it working properly.

Your CGA programs should be 100% compatible with the Tandy 1000, and would need only a little modification for the IBM PCjr. One would have to add a program for the sixteen color 320x200 mode.

NewRisingSun wrote:

Your CGA programs should be 100% compatible with the Tandy 1000, and would need only a little modification for the IBM PCjr.

My test image program doesn't use a standard CGA mode - it's 80-column text mode with some CRTC tweaks to get multiple CRTC scanlines on a single CRT scanline. It's very sensitive to timing, so I don't think it'll work on the 1000TX (which is faster than the 5160) or the PCjr (which is slower). But if you'd like to try anyway, the code is at https://github.com/reenigne/reenigne/blob/mas … res_colours.asm - I think it can be built into a .com file if defaults_com.asm is included instead of defaults_bin.asm. It should look like http://www.reenigne.org/misc/cga_test.png .

NewRisingSun wrote:

One would have to add a program for the sixteen color 320x200 mode.

I think it should be possible to obtain all the necessary calibration data in a single screen in a single mode. Any left/right/phase combination that can be found in 320x200x16 (and more) should also be present in 640x200x4 with a suitable palette.

Are those NASM directives?

Instead of wasting time adjusting timing-sensitive code remotely, I would say just split it up into sixteen or so pictures.

Any left/right/phase combination that can be found in 320x200x16 (and more) should also be present in 640x200x4 with a suitable palette.

But the phase shift will be different. The 320x200x16 mode is basically a 640x200x4 mode that, when the "16 colors" bit is set, latches two 4-bit color numbers and then outputs one 8-bit color number. That takes some time; if one draws a white line from top to bottom and switches the "16 colors" bit on mid-screen, the line will be shifted to the right somewhat.

NewRisingSun wrote:

Are those NASM directives?

I used yasm to build this program (see build.bat in the same directory). nasm might work too with some minor adjustments.

NewRisingSun wrote:

Instead of wasting time adjusting timing-sensitive code remotely, I would say just split it up into sixteen or so pictures.

A nice thing about having it all in one image is that it makes it easier to capture many frames and combine them to get a higher quality capture. The phase of the sampling clock drifts with respect to the pixel clock, so combining many frames yields a capture with a much higher effective sample rate. If it turns out to be prohibitively difficult to get it all on one frame I'll split it up though. At least with PCjr and Tandy we should not have to do any CRTC trickery so I can just poll the status register to do per-scanline palette changes.

NewRisingSun wrote:

Any left/right/phase combination that can be found in 320x200x16 (and more) should also be present in 640x200x4 with a suitable palette.

But the phase shift will be different. The 320x200x16 mode is basically a 640x200x4 mode that, when the "16 colors" bit is set, latches two 4-bit color numbers and then outputs one 8-bit color number. That takes some time; if one draws a white line from top to bottom and switches the "16 colors" bit on mid-screen, the line will be shifted to the right somewhat.

I think it should be possible to handle that separately from the chroma multiplexer array, though. We can shift the RGBI image by any number of high-res pixels before passing it to the composite encoder. Or do you think that the shift in pixel boundaries might be a non-integer number of pixels? The CGA has a latch that ensures that prevents that, but perhaps that doesn't exist on the PCjr and Tandy. If that turns out to be the case then I guess we would have to have a completely separate matrix for that mode.

Well, I have placed the order for the Hauppauge WinTV Impact VCB, and will tell you once I have it.

NewRisingSun wrote:

Well, I have placed the order for the Hauppauge WinTV Impact VCB, and will tell you once I have it.

Awesome. I'll work on getting a test image program.

What software will I be using to capture images? Will that software run in 64-bit Windows 7? I also have an old PCI-slot-bearing machine running Windows 98.

NewRisingSun wrote:

What software will I be using to capture images?

I wrote some custom software to do this. I will put binaries online soon but in the meantime the source for the capture part can be found at https://github.com/crtc-demos/bt8x8cap . It interfaces with the drivers from DScaler 4 (http://deinterlace.sourceforge.net/).

NewRisingSun wrote:

Will that software run in 64-bit Windows 7?

Yes (I run it on a 64-bit Windows 7 machine too).

My thanks to the both of you for continuing this process.