[PATCH] CGA improvements
[PATCH] CGA improvements
This basically ports reenigne's new and vastly improved DOSBox CGA composite emulation to PCem and also has a PCem-specific bugfix by reenigne that fixes the first line being drawn twice in some modes (an artifact that is especially noticable when running 8088MPH). Also adds New CGA emulation which is basically identical to Old CGA, except for the composite mode setting, as well as ability to disable the RGB mode brown circuitry (found a way to do it all inside vid_cga.c), disable composite mode color burst, and also gave the CGA its own composite mode setting (and made it ignore the global setting), all using device_config.
The patch is attached as a RAR file that includes the .patch file, vid_cga_comp.c, and vid_cga_comp.h .
The patch is attached as a RAR file that includes the .patch file, vid_cga_comp.c, and vid_cga_comp.h .
- Attachments
-
- cga_patch.rar
- (5.97 KiB) Downloaded 355 times
Re: [PATCH] CGA improvements
Also, I have an inquiry about the cgapal values. On the Talk page of the CGA article on Wikipedia, I just read this:
However, EGA and VGA are besides the point here. As the specification demands the conversion of the RGBI bits to 4 levels, I think 00, 55, AA, FF would be much better to approximate them.
I see Trixter now agrees on the 00, 55, AA, FF values. However, PCem's cgapal uses 0, 15, 2A, 3F and then bit shifts by two, which I'm not sure is correct for the CGA. It's probably correct for the EGA and for VGA cards with a 6-bit DAC, as those are the effective color values that get produced, though I'd need some documentation on what the EGA and VGA do with them - maybe it gets translated to levels anyway, I'd suspect from 0/63 to 63/63 but I'm not sure.The RGBI color model translates the digital TTL bits to analogue voltage factors of 0, 1/3, 2/3, 3/3. On a digital scale from 0 to 255, that translates to 0, 55, AA, FF. Since the VGA's color registers accept only 6 bits, the scale is from 0 to only 63, which would be 0, 15, 2A, 3F. If you simply multiply these by four (or shift by two bits), which is what most programs do, you'll get 0, 54, A8, FC. In other words, the differences are merely rounding errors. NewRisingSun 20:10, 27 February 2006 (UTC)
The original palette (the one mentioned in "adapted from MC6845 specification") was created by me, using the bit shift method, which is why the values were 54, A8, FC (truncation). I have since re-evaluated that position and now stand by the 55, AA, FF (rounding) numbers because they more closely resemble what they are modeling (ie. full TTL white output = full RGB white output). --Trixter 21:55, 27 February 2006 (UTC)
However, EGA and VGA are besides the point here. As the specification demands the conversion of the RGBI bits to 4 levels, I think 00, 55, AA, FF would be much better to approximate them.
Re: [PATCH] CGA improvements
Here's another version of the patch, but with the cgapal colors changed to the 00, 55, AA, FF model and the bit shifting removed. Sarah now has the choice of whether she agrees with the cgapal change or not, patches are now posted for both with and without it.
- Attachments
-
- cga_patch.rar
- (6.63 KiB) Downloaded 340 times
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: [PATCH] CGA improvements
Made a few changes to the patch :
- Removed the changes to the CGA palette - I intend to remove the 8-bit blitting support for v12, so these will be redundant
- Removed the 'brown' enable bit - once the 8-bit blitting support is removed, this can be implemented if necessary by changing a lookup table rather than by constantly checking colour values in cga_poll()
- Removed the 'color_burst' enable bit - this is already controlled from port 0x3d8, so I don't understand why a separate control is necessary?
- Reworked the config a bit - instead of having 4 config options, just have a single 'display type' list
- Removed some unused variables and cleaned up the code a bit - I'm sure I've asked this before, but can you _please_ follow the coding style in viewtopic.php?f=3&t=5? Please?
Anyway, attached updated patch.
- Removed the changes to the CGA palette - I intend to remove the 8-bit blitting support for v12, so these will be redundant
- Removed the 'brown' enable bit - once the 8-bit blitting support is removed, this can be implemented if necessary by changing a lookup table rather than by constantly checking colour values in cga_poll()
- Removed the 'color_burst' enable bit - this is already controlled from port 0x3d8, so I don't understand why a separate control is necessary?
- Reworked the config a bit - instead of having 4 config options, just have a single 'display type' list
- Removed some unused variables and cleaned up the code a bit - I'm sure I've asked this before, but can you _please_ follow the coding style in viewtopic.php?f=3&t=5? Please?
Anyway, attached updated patch.
- Attachments
-
- cga_comp_v2.patch
- (20.82 KiB) Downloaded 350 times
Re: [PATCH] CGA improvements
I do follow it myself, however the composite code was originally written by reenigne for DOSBox, and I tried to kept it as unmodified as I could.
Also, new composite is a later revision of the CGA card itself, not a display type. The IBM at one point released a slightly revised CGA that did composite mode slightly differently (though it was identical in RGB mode).
Edit: For some reason the cga_color_burst variable is not even set based on 3D8... that needs to be fixed.
Edit #2: It it handled by that, however the use of that setting is to emulate a black&white composite monitor (or TV), since by turning cga_color_burst off, color is never displayed in composite mode.
I think removing the 8-bit blitting support would break the composite code as it relies on being fed color indexes (0x00 to 0x0F) based on which it then calculates the composite mode colors. Using a 32-bit buffer right away would increase the complexity of the code as then in composite mode, you'd have to maintain an 8-bit buffer anyway to feed to the composite mode code.- Removed the changes to the CGA palette - I intend to remove the 8-bit blitting support for v12, so these will be redundant
- Removed the 'brown' enable bit - once the 8-bit blitting support is removed, this can be implemented if necessary by changing a lookup table rather than by constantly checking colour values in cga_poll()
Also, new composite is a later revision of the CGA card itself, not a display type. The IBM at one point released a slightly revised CGA that did composite mode slightly differently (though it was identical in RGB mode).
Edit: For some reason the cga_color_burst variable is not even set based on 3D8... that needs to be fixed.
Edit #2: It it handled by that, however the use of that setting is to emulate a black&white composite monitor (or TV), since by turning cga_color_burst off, color is never displayed in composite mode.
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: [PATCH] CGA improvements
There was use of 4 character tabs and incorrect positioning of braces in the vid_cga.c changes.Battler wrote:I do follow it myself, however the composite code was originally written by reenigne for DOSBox, and I tried to kept it as unmodified as I could.
Well you'd then have a 4-bit RGBI line buffer, which gets written to the main 32-bit buffer either via the composite code, or a lookup table (which would reflect choice of monitor type - RGBI, RGBI w/brown, greyscale etc). It's not that much more complex than what's currently there now.I think removing the 8-bit blitting support would break the composite code as it relies on being fed color indexes (0x00 to 0x0F) based on which it then calculates the composite mode colors. Using a 32-bit buffer right away would increase the complexity of the code as then in composite mode, you'd have to maintain an 8-bit buffer anyway to feed to the composite mode code.- Removed the changes to the CGA palette - I intend to remove the 8-bit blitting support for v12, so these will be redundant
- Removed the 'brown' enable bit - once the 8-bit blitting support is removed, this can be implemented if necessary by changing a lookup table rather than by constantly checking colour values in cga_poll()
Probably a moot point from the user's perspective, but okay.Also, new composite is a later revision of the CGA card itself, not a display type.
Is there any real desire to emulate a black and white composite display? Next you'll be telling me you've added black and white modes to all the graphics cards.Edit #2: It it handled by that, however the use of that setting is to emulate a black&white composite monitor (or TV), since by turning cga_color_burst off, color is never displayed in composite mode.
- Attachments
-
- cga_comp_v3.patch
- (21.37 KiB) Downloaded 345 times
Re: [PATCH] CGA improvements
I'd need to see then which part has this. I don't see any such part in the patch. And regarding the tabs, I generally use Notepad to do my work, and it uses 0x9 for tabs, which is rendered by Notepad as 8 spaces, however other software might render it as 4 spaces.SarahWalker wrote:There was use of 4 character tabs and incorrect positioning of braces in the vid_cga.c changes.
Good point. Then I guess there'd be no problem.Well you'd then have a 4-bit RGBI line buffer, which gets written to the main 32-bit buffer either via the composite code, or a lookup table (which would reflect choice of monitor type - RGBI, RGBI w/brown, greyscale etc). It's not that much more complex than what's currently there now.
Not that I know of, so you might as well remove that. I even talked to reenigne about it and he said disabling color burst wouldn't correctly emulate a black and white display anyway. So it's OK that that option is gone.Is there any real desire to emulate a black and white composite display? Next you'll be telling me you've added black and white modes to all the graphics cards.
All this considered, I'd say the v3 patch is OK.
Edit: Don't forget to add vid_cga_comp.o to the makefiles. :p
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: [PATCH] CGA improvements
Committed at rev 523. Only further change I made was to move vid_vga_comp.* to the dosbox directory.
Re: [PATCH] CGA improvements
After watching this video https://www.youtube.com/watch?v=niKblgZupOc I decided to try CGA Composite mode, but I found it look very different from what we can see in the vid.
Did this patch fix this? I tested PCem 11 official release without any patches
Did this patch fix this? I tested PCem 11 official release without any patches
Re: [PATCH] CGA improvements
First, you probably want to set the game to composite mode, it seems to be set to RGB mode in your screenshot but the screen is composite.
Second, you might want to compile the latest mainline PCem commit as it has reenigne's much better composite filter.
Second, you might want to compile the latest mainline PCem commit as it has reenigne's much better composite filter.
Re: [PATCH] CGA improvements
I enabled composite in the game. The colors are different, but still ugly and nowhere near the picture in the video... I don't have the knowledge to compile, so I will wait for the next releaseBattler wrote:First, you probably want to set the game to composite mode, it seems to be set to RGB mode in your screenshot but the screen is composite.
Second, you might want to compile the latest mainline PCem commit as it has reenigne's much better composite filter.
Re: [PATCH] CGA improvements
Composite mode colors still don't seem to be right
Re: [PATCH] CGA improvements
Good work, Sarah and Battler, thank You. And omarsis81, do notice that this is old rgb tv, and most of the owners have "tweaked" , hue, saturation and brightness, often of every color separately, so you (WE) can not really say that someones tv is accurate. But yeah, doors on tv seems to be black, thats bit odd (off?. The whole blue palette is black).
Re: [PATCH] CGA improvements
It is not just the black if you look closely (character's pants, vases, staircase and the wall) also outside the house, the grass is turquoise where it should be greenszadycbr wrote:Good work, Sarah and Battler, thank You. And omarsis81, do notice that this is old rgb tv, and most of the owners have "tweaked" , hue, saturation and brightness, often of every color separately, so you (WE) can not really say that someones tv is accurate. But yeah, doors on tv seems to be black, thats bit odd (off?. The whole blue palette is black).
Re: [PATCH] CGA improvements
i need to take a look on composite in PCem. the tv screen might be right, after watching the whole video, everything is pretty much explained.
Re: [PATCH] CGA improvements
Nothing is as easy as it looks, i did it on Tandy 1000 sl/2 and game allow me to switch modes on the fly, mahine had set CGA display adapter and when i used CGA in game it looks horribly, but after switching to Tandy in game , while still using CGA display adapter , the game looks lovely, pretty amazing. Tandy is backwards compatible only with CGA and PCem CGA displays the Tandy very nicely. But when i used new hardware and CGA display adapter , i was not able to switch modes on the fly and CGA looks like on Omarsis81 screen, he was also using modern board. very strange, composite CGA emulation on tandy 1000 sl/2 looks exactely like on first laptop in video but it must be switched to Tandy (shift+T) cos on CGA setting in game it looks like shit, i could not switch to EGA graphics. i think it can be fixed easyly, b cos of that Tandy thing, but i m not a programmer, and more research needs to be done. one thing is for sure, CGA behave diferentely while are emulated on different era mainboards. screens are signed accordingly. (on first tandy 1000 it only happend right if mahine display is set to rgb, and you can not set display adapter options, where on 1000 sl/2 you can not set options on mahine display but you can on display adapter, and when i set composite it looks as if it was on RGB as in original tandy 1000)
- Attachments
-
- maniac cga composite old (tandy in game).jpg (102.1 KiB) Viewed 12663 times
-
- maniac cga composite old (cga in game).jpg (125.02 KiB) Viewed 12663 times
-
- maniac cga composite old(no modes).jpg (88.04 KiB) Viewed 12663 times
Last edited by szadycbr on Wed 22 Mar, 2017 6:30 pm, edited 1 time in total.
Re: [PATCH] CGA improvements
and please watch everybody, whole video,it will tell you everything.
Re: [PATCH] CGA improvements
The problem is that the composite code right now is only for CGA. It's a simple port to PCem of reenigne's accurate composite CGA emulation for DOSBox. He has not implemented the emulation of composite Tandy or PCjr yet.
Edit: And if the problem is with *CGA*, then try switching the card's variant from old (default) to new CGA, maybe the video was made using new CGA (which seems to be more common).
Edit: And if the problem is with *CGA*, then try switching the card's variant from old (default) to new CGA, maybe the video was made using new CGA (which seems to be more common).