DosBox' implementation is a lot more simplistic. If you want me to post pictures of my actual program's output, mention the name of and the place within the game or program in question, and I'll post it. Meanwhile, here are two pictures, one is the palette in "640x200 with color burst" mode, the other from King's Quest 1, at different settings of the virtual TV's "hue" knob.

NewRisingSun wrote:

If you want me to post pictures of my actual program's output, mention the name of and the place within the game or program in question, and I'll post it.

It's not the program's output I want to see, it's the algorithm. Will you be releasing the source? Maybe we can work on optimizing it to a level where it could be included in DOSBOX.

If not, DOSBOX will have to just pick a palette to map colors to, I guess.

Qbix wrote:

The screenshots I posted in the first page look a lot like those two of NewRisingSun. (they are of the same games, although NewRisingSuns algorithm is has some more complex features)

Looks good, but too dark as previously mentioned. You should allow the user the option to adjust the overall level of the output.

And as far as the composite output in regular modes is concerned (not the artifact colors, but the normal modulated colors), the colors follow their RGB colors except for your color 6.

In the previous post, you showed us the 16 composite color palette and while there are similarities, there are substantial differences regardless of hue. I can assume as King's Quest uses the artifact color composite mode (640x200) and not the modulated color composite mode (320x200), the palette would be different.

Great Hierophant wrote:

I can assume as King's Quest uses the artifact color composite mode (640x200)

That's right. King's Quest I first starts in 320x200x4 mode (bios mode 4) and then sets 640x200x2 mode with color burst (port 3d8=1a) manually so the BIOS will think it's in still 320x200 mode and thus print all text at double-width. KQ1 really is that dark, so an accurate emulation should reflect that.

Trixter wrote:

Will you be releasing the source?

It's not presentable at the moment. I have already sent it to Blargg; he has made some optimizations to the NES portion, and I'm currently trying to figure them out and incorporate them into the main code. If I sent it to somebody else now for further "optimizations", I would completely lose track.

Trixter wrote:

Maybe we can work on optimizing it to a level where it could be included in DOSBOX.

DosBox needs to support HiColor mode first --- proper NTSC color processing involves a lot of filtering which results in many transient-colored pixels that can't be done properly in 256-color palettized modes. Before that support is added, DosBox support is out of the question.

If you want to help optimize it, you can post a schematic of the CGA, please; looking at your calibration page, I assume that you have one. I currently get my information from the CGA patent, but it seems that they slightly deviated from that in some aspects, as my colors are a little too bright in a few cases. Or maybe I'm just interpreting the diagrams in the patent incorrectly.
Just taking away some brightness is not possible, because for games that use cross-color artifacts in 320x200x4 mode, the relationship between luma amplitude and chroma amplitude is delicate to properly yield the 'correct' artifact colors. In the "normal" (640x200x2 based) composite color mode, this is not a problem, because you're just getting artifact colors from white pixels; therefore, games that use this mode will look right no matter what I do. It's the Ultima2/3/Decathlon that are the problem.

Look at these eBay auctions:

http://cgi.ebay.com/Vintage-IBM-5153-CGA-RGB- … 1QQcmdZViewItem

http://cgi.ebay.com/Vintage-IBM-5153-CGA-RGB- … 1QQcmdZViewItem

Two 5153s, while the seller isn't using an IBM CGA card, the color is brown. There are also controls on the back of the CGA, one may be used for calibrating the color. Therefore, I believe I was wrong in believing that the color could have been anything other than brown.

Great Hierophant wrote:

Two 5153s, while the seller isn't using an IBM CGA card, the color is brown. There are also controls on the back of the CGA, one may be used for calibrating the color.

No, the controls on back are, left to right, "V.SIZE" and "V.HOLD". There are pots inside the monitor that you can use to adjust the red gun, but most consumers don't go inside their monitor (and it would adjust all colors so this isn't what the owner of the 5153 in the photos did).

The previous person who had the monitor that didn't display brown probably has a dry joint at the base of Q206 (in the schematic). That would effectively kill the "brown circuit".

NewRisingSun: There is no copyright year on any of the pages, I am told (I got the tech ref schematic page from a friend). IBM released updates occaisionally, in the form of 3-hole pages you stuck into the binder, but the person I got the page from doesn't recall ever getting a CGA or 5153 update. I do have a PCjr tech ref, but it's in my crawlspace and I don't know if it has the kind of info you're looking for. I'll try to find it.

It is difficult to distinguish between the non-intense and the intense CGA colors on those auction pictures, except for the brown/yellow. Cany you distinguish between black and dark gray on a real 5153 without touching your nose to the screen.

Great Hierophant wrote:

It is difficult to distinguish between the non-intense and the intense CGA colors on those auction pictures, except for the brown/yellow. Cany you distinguish between black and dark gray on a real 5153 without touching your nose to the screen.

Certainly, but it all depends on the brightness control (the one that does NOT look like a half-moon), and both the contrast and brightness front-panel controls lack a center/default setting. So if you turn one all the way left, and the other all the way right, you can make the hi-intensity colors look identical to the low-intensity colors... reverse the knobs, and reverse the effect. That's why I put together http://www.oldskool.org/pc/cgacal so that people could calibrate their monitors properly.

FYI, I finally managed to get in contact with someone who worked at IBM during the design phase of the PC (he wasn't directly involved but worked in another department) and this is how he explained why extra circuitry was added to turn #6 darker brown:

...It was for 3270 emulation. They wanted to match the color pallet of the 3270 (3278? 3279?) color display.

The only use IBM could forcast for PCs was as terminals on a mainframe. They spent a lot of time insuring it would be able to do a "proper" 3270 emulation.

I don't know about the use of the phrase "the only use", but mainframe compatibility is evident in other design decisions; the XT, for example, has special timing on the 8th slot and as a result can usually only be used with the async cards used to connect to mainframes, or the 5161 expansion chassis.

Anyway, thought people would like to know.

MobyGamer wrote:

FYI, I finally managed to get in contact with someone who worked at IBM during the design phase of the PC

(...)

Anyway, thought people would like to know.

Jim, as always, you rule! 😀 Now of course there's the next question: why did this terminals have brown instead of dark yellow??? 😀

JAL

jal wrote:

Jim, as always, you rule! 😀 Now of course there's the next question: why did this terminals have brown instead of dark yellow??? 😀
JAL

Don't care, since that's outside of the scope of dosbox 😀

I don't rule yet; I have yet to produce a schematic of the CGA card itself for NRS.

And last night I had a CGA kick my ass; I came up with usuable 40x50 and 80x50 modes on my 5150 but they didn't work on my 5160 (both are IBM CGA cards but the 5160 has a newer card (date is 1986, pretty late for a full-length card). Which sucks, since I had some cool demo effects running in 40x50...

And last night I had a CGA kick my ass; I came up with usuable 40x50 and 80x50 modes on my 5150 but they didn't work on my 5160 (both are IBM CGA cards but the 5160 has a newer card (date is 1986, pretty late for a full-length card). Which sucks, since I had some cool demo effects running in 40x50...

I take it that switching putting the '86 card in the 5150 and the old card in the 5160 didn't fix the problem?

Don't care, since that's outside of the scope of dosbox

No plans to add 3270PC emulation to dosbox, then? 😈

Great Hierophant wrote:

And last night I had a CGA kick my ass; I came up with usuable 40x50 and 80x50 modes on my 5150 but they didn't work on my 5160 (both are IBM CGA cards but the 5160 has a newer card (date is 1986, pretty late for a full-length card). Which sucks, since I had some cool demo effects running in 40x50...

I take it that switching putting the '86 card in the 5150 and the old card in the 5160 didn't fix the problem?

Nope. The 5150's oscillator is slightly off; when I test it with MIPS.COM, the numbers all read like 1.02, 1.04, 1.01, etc. On the 5160, the numbers are 1.00 across the board. So I'm guessing my 50-line modes are an artifact of sheer luck with the goofy crystal 🙁

It's got to be possible but I just haven't found it yet. All my numbers (vertical total, vertical sync position, etc.) say it should work, but it isn't stable on the 5153 (rolls).

Hey, I figured it out! I made a mistake in my original mode set calculations (my Veritcal Total Adjust was way off) and have no idea why the original 5150 displayed it fine, but here's a working config:

40x50 and 80x50: (horizontal registers are identical to ??x25 modes) (numbers in decimal)

Vertical Total=62
Vertical Total Adjust=12
Vertical Displayed=50
Verticla Sync Position=56
Maximum Scanline=3

So if I get hit by a bus, now you know how to make 50-line modes (the 80x50 is good for using #177 for an effective 80x50 136-color mode).

FYI, I've also duplicated the 256x200 mode 4-color mode used by an early Asteroids-clone game, I think most of you know what I'm talking about. I've also created a 160x200 mode that is a skinny column in the middle of the screen (2 real video pages) and also a 320x100 "widescreen" mode centered in the middle of the screen (also 2 video pages)... not sure how useful these are, but if DOSBOX ever wants to test compatibility for this stuff, or other raster-based tricks like copper bars (yes, in CGA) I can provide working code, just let me know.

FYI, I've also duplicated the 256x200 mode 4-color mode used by an early Asteroids-clone game, I think most of you know what I'm talking about. I've also created a 160x200 mode that is a skinny column in the middle of the screen (2 real video pages) and also a 320x100 "widescreen" mode centered in the middle of the screen (also 2 video pages)... not sure how useful these are, but if DOSBOX ever wants to test compatibility for this stuff, or other raster-based tricks like copper bars (yes, in CGA) I can provide working code, just let me know.

I sincerely doubt that DOSBox would be able to handle many of these tweaked modes, especially as it cannot display two of the most important tweaked-cga games properly. On the other hand, it has no problem with seemingly any game that uses the 160(80)x100 mode.

Great Hierophant wrote:

I sincerely doubt that DOSBox would be able to handle many of these tweaked modes, especially as it cannot display two of the most important tweaked-cga games properly. On the other hand, it has no problem with seemingly any game that uses the 160(80)x100 mode.

What are those two games?

MobyGamer wrote:

What are those two games?

Probably GH refers to the 16 color 160x100 mode, like Round42 and Bricks? DOSbox indeed doesn't have problems with it, but it's not the most heavily tweaked mode ever, and doesn't rely on changing sync parameters, afair.

JAL

Maybe he is referring to some mode-x tweaked VGA modes such as 400x320 360x240 and so on.