ripsaw8080 wrote:

The games in the videos appear to be using mode 8/9 16-color graphics, and although the PCjr does have a composite out, things will look better in general with a RGB monitor hooked up to the RGB out. If you're suggesting some kind of composite output for all modes, that would seem to be beyond the scope of the current patch.

No, only for modes 4-6 - the 16-color modes would indeed be too much for the paletted approach (and I can't think of anything that actually used the 16-color modes for artifact color generation, anyway).

At any rate, games that absolutely need both composite video and machine=pcjr/tandy are rare indeed, so maybe that's best left for later, if at all.

Servo wrote:

In mode 4 the artifact colors on the PCjr are different than both CGA and Tandy (I have no idea how far the hue is offset by; if any one is interested I can do some captures when I get a chance). Offhand the only game I can think of that utilizes this is Below the Root; it's really CGA mode 4 no matter what machine you have, but on a PCjr it uses different color patterns so on a composite monitor the results look similar to the CGA composite version. In mode 6 I think PCjr should be same as new CGA with no offset (though that's from memory, I would need to double check that).

Since the 16 solid/chroma colors appear to be the same as new CGA, at least in the abovementioned videos, I find it a bit odd that the artifact colors should be any different. But yes, a few representative captures could be interesting if you get a chance.

I tried to check what Below the Root does when it detects a PCjr, but DOSBox didn't get me very far - with machine=pcjr I can hear 3-voice music and then gameplay sounds, but the screen is just blank. My test copy is a DOS conversion, so I don't know if they broke something while converting it, or it's original behavior that DOSBox is choking on.

Great Hierophant wrote:

Run the below program and take pictures of the output, that will show what the colors are supposed to be.

CHART.COM seems to be using 0x3d8/9, so I don't think it'll give the desired results on a real PCjr.

Below the Root seems to work in PCjr mode in DOSBox 0.73, but not 0.74.
(And hello, I've been fascinated with this thread for awhile, but been lurking)

Reiver102 wrote:

Below the Root seems to work in PCjr mode in DOSBox 0.73, but not 0.74.
(And hello, I've been fascinated with this thread for awhile, but been lurking)

I played with both dosbox 0.73 and 0.74 with PCjr mode. I see no different with the two version.

If you have problems with Below the Root with dosbox 0.74, please start a new topic.

Below The Root works with machine=pcjr in official releases, but has a problem in SVN when the game calls INT 10h/AH=0Bh/BH=08h/BL=00h. BH=08h is a strange subfunction number, but DOSBox treats it the same as BH=01h, thus selecting palette 0.

There appears to be a bug in INT10_SetColorSelect(). I've attached a patch with a proposed solution, but Hal probably has a better idea.

Great Hierophant wrote:

Run the below program and take pictures of the output, that will show what the colors are supposed to be.

CHART.COM seems to be using 0x3d8/9, so I don't think it'll give the desired results on a real PCjr.[/quote]

It will give nothing since those registers do not exist in PCjr. That is reengine's program, ask him for something that would work in a Jr.

Great Hierophant wrote:

It will give nothing since those registers do not exist in PCjr. That is reengine's program, ask him for something that would work in a Jr.

your last post seemed to suggest that Servo should take pictures of it running on a PCjr, hence my reply. Must have misread or something.

ripsaw8080 wrote:

Below The Root works with machine=pcjr in official releases, but has a problem in SVN when the game calls INT 10h/AH=0Bh/BH=08h/BL=00h. BH=08h is a strange subfunction number, but DOSBox treats it the same as BH=01h, thus selecting palette 0.

There appears to be a bug in INT10_SetColorSelect(). I've attached a patch with a proposed solution, but Hal probably has a better idea.

Thanks - BtR seems to work fine with this. I can see the different pixel patterns that Servo is talking about, but the palette is different too: intensity is on for white, but off for cyan and magenta. Somehow I doubt that this should be the case on a real PCjr (can't see how low-intensity artifact colors could be hue-shifted to match the game's hi-intensity look on CGA, for one).

I can see the different pixel patterns that Servo is talking about, but the palette is different too: intensity is on for white, but off for cyan and magenta. Somehow I doubt that this should be the case on a real PCjr (can't see how low-intensity artifact colors could be hue-shifted to match the game's hi-intensity look on CGA, for one).

Hmm, I don't see that with the official 0.74 release; an oddity with the patch? I can't say I remember exactly what a real PCjr does; my PCjr's RGB monitor died a while ago so I can only use composite at the moment. Either case, the PCjr's colors on a composite display are not exactly the same as with CGA in color and intensity for this game; what I meant was that they are similar though not exact (ie. tree's are still brown but slightly different color/intensity, leaves are still green but with different color/intensity, etc. I believe without the different pixel patterns the colors would have been much further off and not made sense). I'll have some time this evening and will create a few captures to illustrate.

Servo wrote:

Hmm, I don't see that with the official 0.74 release; an oddity with the patch? I can't say I remember exactly what a real PCjr does; my PCjr's RGB monitor died a while ago so I can only use composite at the moment.

from what I see (in a few other threads as well), I guess there have been some regressions since 0.74 when it comes to PCjr video, so the colors in 0.74 could very well be correct.

Either case, the PCjr's colors on a composite display are not exactly the same as with CGA in color and intensity for this game; what I meant was that they are similar though not exact (ie. tree's are still brown but slightly different color/intensity, leaves are still green but with different color/intensity, etc. I believe without the different pixel patterns the colors would have been much further off and not made sense). I'll have some time this evening and will create a few captures to illustrate.

I took the Jr title screen from 0.74 (with the presumably-correct colors; same as your attached image), and loaded it up in PC Paint using composite CGA - just to see if I could find a hue adjustment to mimic the difference between new CGA and PCjr.

You can see the results below... no amount of hue adjustment seems to get the leaves anywhere near green when the trees are even remotely brown (and vice versa). Guess the CGA/PCjr difference is somewhat more complex than a simple hue shift, then - should be interesting to see those captures if you get the chance.

You can see the reason for the mixed intensity of palette 1 in the INT10_SetColorSelect() function (the one changed in the above patch), where it's using entries 3, 5, 0xf. You can change the entries for both palette 0 and 1 to all intense colors with:

1         case M_TANDY4:
2             for(Bit8u i = 0x11; i < 0x14; i++) {
3-                const Bit8u t4_table[] = {0,2,4,6, 0,3,5,0xf};
4+                const Bit8u t4_table[] = {0,0xa,0xc,0xe, 0,0xb,0xd,0xf};
5                 IO_Write(VGAREG_TDY_ADDRESS, i);
6                 IO_Write(VGAREG_PCJR_DATA, t4_table[(i-0x10)+(val&1? 4:0)]);
7             }
8             break;

However, what would seem to make more sense is to add 8 to a table of non-intense entries depending on some intensity bit, but I don't know where such a bit would come from for PCjr... perhaps the palettes are always intense? Also, the above modification will only help for RGB, the composite colors are currently using the intensity bit from port 3D9h, which doesn't exist for PCjr. Maybe you could assume intensity is on for the purpose of testing PCjr composite colors...

I think these palette issues are due to the removal of port 3D8h/3D9h for PCjr and newly implementing palette stuff on port 3DAh. It's important to remember that SVN source should not be considered stable, even though it tends to be relatively stable because the devs are careful with their commits.

From a glance at the PCjr tech ref (@ http://www.retroarchive.org/dos/docs/index.html) - the video gate array has 16 palette registers, addressed 10h-1Fh, which determine what color to display when reading color index values 0h-Fh from memory. In 4-color modes, only the first 4 registers are used. This sets R, G, B as well as intensity for each individual color - you're free to choose your 4 colors, unlike CGA (see Alley Cat).
That's all I know for now. INT10,B should work the same as CGA so palette 0/1 can be selected that way, but I'm guessing it's up to the game to set the intensity as above.

This raises the question, should we try and fiddle with composite support for PCjr before the rest of the pcjr-specific video stuff is fixed... doing the latter isn't really a job for this patch.

Looking at the PCjr BIOS disassembly for function 0Bh of INT 10h at offset E543h in the ROM, the first instructions are "MOV DX,3DAH / IN AL,DX" so my .diff patch is correct according to the BIOS.

However, DOSBox SVN is doing exactly what the PCjr BIOS does regarding the palette entries. Palette 1 has entries 0, 3, 5, 0xf; so it appears the white is intense while the other colors are not, as strange as it may seem...

Not that strange. In mode 10, the 4 colours have the same palettes than the mode 4. CGA-PCjr is made that way.

I played with both dosbox 0.73 and 0.74 with PCjr mode. I see no different with the two version.

If you have problems with Below the Root with dosbox 0.74, please start a new topic.

You're right; my mistake, I was using ykhwong's 0.74 build instead of the regular 0.74; it works fine in the regular version. But anyway, wasn't posting that with the intent of resolving that particular issue, merely trying to assist with the current project at hand, however I can. I really dig what you all are doing here 😁

Ok, I made a few captures. Turns out my memory was off, the colors are more different than I remembered. Based on the composite display, the high intensity white and low intensity other colors is actually correct; many of the colors are very dark! It made my captures from the game quite dark/blurry at times. (EDIT: ok maybe not, comparing to the test maybe those are all high intensity...) I also put together a basic program to show all 16 colors; I also did a capture with this on both my PCjr and PC/CGA (along with the RGB version captured in DOSBox 0.74). Captures attached, I'll be interested if you can figure out what's going on!

Reiver102 wrote:

You're right; my mistake, I was using ykhwong's 0.74 build instead of the regular 0.74; it works fine in the regular version. But anyway, wasn't posting that with the intent of resolving that particular issue, merely trying to assist with the current project at hand, however I can. I really dig what you all are doing here 😁

Eh, that happens - with so many builds around I initially forgot to test with plain ol' 0.74 too.
Also, welcome. Nice to see someone relatively new who's actually interested in emulating anything pre-Voodoo 😉

Servo wrote:

Ok, I made a few captures. Turns out my memory was off, the colors are more different than I remembered. Based on the composite display, the high intensity white and low intensity other colors is actually correct; many of the colors are very dark! It made my captures from the game quite dark/blurry at times. (EDIT: ok maybe not, comparing to the test maybe those are all high intensity...) I also put together a basic program to show all 16 colors; I also did a capture with this on both my PCjr and PC/CGA (along with the RGB version captured in DOSBox 0.74). Captures attached, I'll be interested if you can figure out what's going on!

Very interesting, this... looks like the pure chroma colors (columns 0, 5, 10, 15 in your "scrtest" shot) are practically the same as new CGA, and looking at them alone, they do match the premise of hi-intensity white and low-intensity cyan/magenta. But as soon as they're blended (all other columns), a different amount of hue shifting seems to kick in in each case.
To test, I tried to force this palette (0, 3, 5, 0xF) in the composite calculation code, and you can see the results [EDIT- removed, see new post below]

It's sort of interesting that this mode artifacts in green and purple: rather Apple II-like. From an aesthetic point of view, I'm liking the PCjr look of Below the Root - very forest-like, for lack of a better term. 🤣

Here's another comparison, assuming that the 0/3/5/F palette is correct, as ripsaw pointed out. Still not sure what to make of it.

leaving the PCjr aside for a bit, here's an update of the composite CGA patch (against SVN). This addresses the changes discussed on the last page:

• Most of the key variables are now set in the config file, and changeable from the command line
• Hard-coded optimal saturation values (for both old and new CGA); correct color transformation / NTSC black level compensation applied
• Hue (F11/alt-F11) and composite auto/on/off (F12) can be controlled from the keyboard as well as the config/cmdline - much like setting the cpu cycles.

This seems to be the most flexible way to do things: you can control your parameters from a multiple config setup, from a frontend profile, from batch files to run internally, and so on.

Adding an entirely new config file section seems to involve way more OOP than I'm comfortable with, so for now I just stuck the composite-related properties under [render].
They are:

1#    composite: Emulate a composite display for CGA machines. Can be toggled with F12.
2#               Auto detection (auto) will only work for 640x200/mode 6 games.
3#               Possible values: auto, true, false.
4#      cgatype: Type of CGA card to emulate when machine=cga: old (P/N 1501486) or new (P/N 1501981).
5#               Affects composite output only.
6#               Possible values: old, new.
7# tvbrightness: Adjust the brightness of the emulated composite display (percentage, 0-100).
8#               Most games won't need any change.
9#        tvhue: Adjust the hue offset of the emulated composite display (phase degrees).
10#               Can be increased/decreased with (ALT)F11.

and the defaults:

1composite=auto
2cgatype=old
3tvbrightness=100
4tvhue=0

Any comments about this implementation? I guess this makes the patch pretty much good to go (leaving aside the question of pcjr/tandy)... if anyone wants to "prettify" it and/or move this stuff to a dedicated [composite] section then go right ahead.

I think I figured out what's going on with the PCjr's artifact color generation... or at least I seem to be thereabouts.

In Servo's "scrtest" capture, The solid chroma colors (cyan and magenta) are the same as new CGA, but the blended colors aren't; empirically, that seems to mean that the 6 chroma signals are all shifted by some phase angle (compared to CGA), and somewhere else (pixel clock? color carrier?) there's a reverse shift which exactly counters that. In the code, this means we add a certain value to each of phases[6], then adjust hue/tint the usual way by the negative of that value.

The PCjr's difference seems to be somewhere between 115 and 130 degrees (positive in the chroma signal phases, negative in hue control). Or more to the point: 130 seems a better match for some of the colors in Servo's captures, and 115 for others. For instance 115 seems to play nicer with the greens and the magentas, but it also makes the dark brown turn green, which is bad news for Below the Root.

That must mean that some relatively tiny adjustments are needed elsewhere, but I have no idea what they would be (different pixel delays?). See attachments for the results with 115 vs. 130. The underlying RGB palette is indeed dark cyan/dark magenta/bright white.

@Servo: if you get the chance, could you possibly provide a PCjr capture of that scrtest program using palette 0 (green/red/brown)?
 

[Thread moved to DOSBox Development Section as suggested]

Ok, here's a few captures with palette 0 low intensity.