VOGONS

Common searches


Reply 640 of 758, by VileR

User metadata
Rank l33t
Rank
l33t
Great Hierophant wrote:

On a real IBM PC with an IBM CGA card even I had trouble with Jungle Hunt getting the white status bar text all the time. It would usually cycle its location on the screen each time you died.

Well, that's what DOSBox does as well now; better than not at all. ;)

By the way, your IBM CGA is 'new-style' as well, isn't it? I wonder if you can corroborate my impression above, about the saturation/contrast/brightness adjustments. It holds true for what we've seen from Servo's card, plus Trixter and Scali (who own newstyle CGA cards that we've been testing for a final version of the demo).

Specifically, it seems that the following adjustments bring it much closer to a real new-style CGA's output:
* +30 saturation offset
* +50 contrast offset
* -30 brightness offset
(or thereabouts!)

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 641 of 758, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
VileRancour wrote:
Well, that's what DOSBox does as well now; better than not at all. ;) […]
Show full quote
Great Hierophant wrote:

On a real IBM PC with an IBM CGA card even I had trouble with Jungle Hunt getting the white status bar text all the time. It would usually cycle its location on the screen each time you died.

Well, that's what DOSBox does as well now; better than not at all. 😉

By the way, your IBM CGA is 'new-style' as well, isn't it? I wonder if you can corroborate my impression above, about the saturation/contrast/brightness adjustments. It holds true for what we've seen from Servo's card, plus Trixter and Scali (who own newstyle CGA cards that we've been testing for a final version of the demo).

Specifically, it seems that the following adjustments bring it much closer to a real new-style CGA's output:
* +30 saturation offset
* +50 contrast offset
* -30 brightness offset
(or thereabouts!)

Actually I have both a new-style and an old-style CGA card. The old-style card has a Motorola 6845 and the new-style card has a Hitachi 6845. What do you think I could accomplish with a CRT, these cards and Jungle Hunt?

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 642 of 758, by VileR

User metadata
Rank l33t
Rank
l33t

Well, neither of those cards is going to change much for Jungle Hunt, at least if we're talking about the "wandering white scanlines" issue - that's just shoddy code, I'm afraid.

I was just considering new-style CGA emulation in general, and which brightness/saturation/contrast adjustments it should have by default. In current SVN (as well as the newest patch), these values are somewhat 'safe', but they don't actually look like the real-life output of any new-style CGA card that we've seen and/or tested. The offsets I'm proposing (only for new CGA) would seem to fix that.

Attached is a version of the patch (+ binary) with adjustments applied. The difference should be quite visible --

Current new-CGA (no adjustments):

newCGA_noAdj.png
Filename
newCGA_noAdj.png
File size
50.19 KiB
Views
2328 views
File license
Fair use/fair dealing exception

Adjusted new-CGA (EDIT: a less extreme and more elegant solution - just double the saturation for new CGA):

newCGA_Adjusted3_satX2.png
Filename
newCGA_Adjusted3_satX2.png
File size
49.93 KiB
Views
2309 views
File license
Fair use/fair dealing exception

...and compare here, here, here and here, but these results should still be closer to a real card's output in any case.

I (bluntly) applied the change as follows...

double mode_saturation = (new_cga ? 5.8 : 2.9)*saturation/100;

(EDIT: Just double the saturation for new CGA. Also: increments for brightness/contrast/saturation are now 5 instead of 10.)

Attachments

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 643 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

Luma should not be filtered at all when the color burst is off.

Here's a version of the patch that turns off the 3.57MHz filtering when there's no burst (this also incorporates VileRancour's recent suggestion). If you also disable the 7.16MHz filter by turning the sharpness up to 100, the result looks a lot like RGBI output (except for the lack of colour) unless you zoom into a screenshot and see that the CGA pixels are no longer centered on the host's pixels.

Attachments

Reply 644 of 758, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

So which is more likely to happen first? Proper MC6845 emulation or Tandy/PCjr. composite color implementation?

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 645 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
Great Hierophant wrote:

So which is more likely to happen first? Proper MC6845 emulation or Tandy/PCjr. composite color implementation?

That depends on whether someone can get me the calibration data I need from a Tandy and/or a PCjr before I get around to the CRTC work.

To get the calibration data I need the machine in question to display a certain test pattern while hooked up to a capture card that can capture raw composite (ideally a Hauppage ImpactVCB 00166 but anything that uses a Conexant Fusion 878A or even another Brooktree 848 compatible chip should work).

Reply 646 of 758, by Scali

User metadata
Rank l33t
Rank
l33t
reenigne wrote:
Great Hierophant wrote:

So which is more likely to happen first? Proper MC6845 emulation or Tandy/PCjr. composite color implementation?

That depends on whether someone can get me the calibration data I need from a Tandy and/or a PCjr before I get around to the CRTC work.

To get the calibration data I need the machine in question to display a certain test pattern while hooked up to a capture card that can capture raw composite (ideally a Hauppage ImpactVCB 00166 but anything that uses a Conexant Fusion 878A or even another Brooktree 848 compatible chip should work).

I would be very interested in some 'test cards' for PCjr/Tandy as well.
I have two clone CGA systems which have composite output, but the artifact colours are completely different from CGA. So I wonder if they cloned PCjr's colours instead. These cards are Plantronics-compatible, so like the PCjr, they have 16-colour RGBI modes. With artifacting, you can get more than 16 colours.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 647 of 758, by VileR

User metadata
Rank l33t
Rank
l33t
Scali wrote:

I have two clone CGA systems which have composite output, but the artifact colours are completely different from CGA. So I wonder if they cloned PCjr's colours instead. These cards are Plantronics-compatible, so like the PCjr, they have 16-colour RGBI modes. With artifacting, you can get more than 16 colours.

Even the Tandy 1000 series didn't bother preserving the PCjr's artifact colors - and that was explicitly based on the PCjr.
Makers of clone hardware were probably satisfied as long as the 16 'direct colors' looked right; artifact colors may still be different (depending on the relationships between the various components of the signal), and in practice they were probably a function of each particular circuit design.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 648 of 758, by VileR

User metadata
Rank l33t
Rank
l33t
reenigne wrote:

(this also incorporates VileRancour's recent suggestion)

I believe I have a somewhat better one. Just doubling the saturation looks alright overall, but causes the fringing (and clipping) to be a little more prominent. Besides, as you've already mentioned, new CGA's difference would be more accurately modeled by adding a change of contrast.
After experimenting a little, I found a more balanced approach:

(vga_other.cpp @ 239)

mode_contrast *= contrast * (new_cga ? 1.2 : 1)/100;             // new CGA: 120%
mode_brightness += (new_cga ? brightness-10 : brightness)*5; // new CGA: -10
double mode_saturation = (new_cga ? 4.35 : 2.9)*saturation/100; // new CGA: 150%

The difference may not be very apparent, but the fringing on white text is slightly better, and clipping (on the extreme ends of the palette) is reduced a little. It works well enough with any new CGA thing I throw at it:

newCGA_Adjusted4.png
Filename
newCGA_Adjusted4.png
File size
50.72 KiB
Views
2237 views
File license
Fair use/fair dealing exception
newCGA_Adjusted4b.png
Filename
newCGA_Adjusted4b.png
File size
134.5 KiB
Views
2237 views
File license
Fair use/fair dealing exception

I added this to your newest version - here's the updated patch.
(The binary here also includes the scaler patch which may come in handy for the double-height composite modes.)

Attachments

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 649 of 758, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
reenigne wrote:
Great Hierophant wrote:

So which is more likely to happen first? Proper MC6845 emulation or Tandy/PCjr. composite color implementation?

That depends on whether someone can get me the calibration data I need from a Tandy and/or a PCjr before I get around to the CRTC work.

To get the calibration data I need the machine in question to display a certain test pattern while hooked up to a capture card that can capture raw composite (ideally a Hauppage ImpactVCB 00166 but anything that uses a Conexant Fusion 878A or even another Brooktree 848 compatible chip should work).

The Hauppage card looks reasonably affordable, but there is a PCI-E version, the 01381, and the only computer I have with a regular PCI slot is in a system is from 1999. If the PCI-E version can handle raw composite video and can also handle 240p correctly, I would seriously consider buying it.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 650 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
Great Hierophant wrote:

The Hauppage card looks reasonably affordable, but there is a PCI-E version, the 01381, and the only computer I have with a regular PCI slot is in a system is from 1999. If the PCI-E version can handle raw composite video and can also handle 240p correctly, I would seriously consider buying it.

The 01381 uses a CX23885 which seems to be too different from CX878A to work with my existing software. Linux has a VBI driver for it so it's probably possible, but it would be a lot of work to adapt the software.

The calibration program should run on a 1999 machine with no problems as long as it can run Windows XP. I was using it with a Athlon XP 1800+ until this year. I don't know if you'd be able to capture video without dropping frames but that doesn't matter for the calibration process.

Reply 651 of 758, by Scali

User metadata
Rank l33t
Rank
l33t
VileRancour wrote:
Scali wrote:

I have two clone CGA systems which have composite output, but the artifact colours are completely different from CGA. So I wonder if they cloned PCjr's colours instead. These cards are Plantronics-compatible, so like the PCjr, they have 16-colour RGBI modes. With artifacting, you can get more than 16 colours.

Even the Tandy 1000 series didn't bother preserving the PCjr's artifact colors - and that was explicitly based on the PCjr.
Makers of clone hardware were probably satisfied as long as the 16 'direct colors' looked right; artifact colors may still be different (depending on the relationships between the various components of the signal), and in practice they were probably a function of each particular circuit design.

Perhaps... but both my Paradise PVC4 and ATi Small Wonder seem to generate the same artifact colours in mode 4.
And my first impression on seeing the PCjr capture of 8088 MPH is that these artifact colours are the same.
It could be coincidence rather than a conscious attempt to minic the colours, but still, it's possible that they're the same. After all, it's just about the phase of the colorburst vs the pixels.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 653 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

After all, it's just about the phase of the colorburst vs the pixels.

There's a bit more to it than that. There's the phase of the pixels (BIOS mode 6 artifact colours) and the phases of the 6 direct colours (blue, green, cyan, red, magenta and yellow). But even knowing all those doesn't give you the full picture because when you switch from one colour to another colour it isn't an instantaneous transition from the left-pixel-waveform to the right-pixel-waveform at the pixel boundary - signals take time to rise and fall and propagate through logic gates.

What it comes down to is that generating composite colour the way that these machines do it, the colours generated are very sensitive to the analogue behavior of digital circuitry. In particular (for the CGA) the critical chip is the 74LS151 which multiplexes the 8 colour signals (not including the intensity bit) according to the current pixel colour. The 256-element table in my patch contains all the necessary information about the analogue behavior of this chip (as measured from captured output of my CGA card). Fortunately different samples of this chip seem to have reasonably similar behavior, or the images in 8088 MPH would not be consistent between even different old CGA cards. Also, since the same chip is used in old and new CGA cards, we can use the same table for both (just adjusting the values of the simulated DAC resistors which come after the multiplexer).

However, neither PCjr nor Tandy use this multiplexer chip - they implement the same logic in gate arrays. With a different circuit and different process technology it would be pretty unlikely for the colours to be the same. Even if they made an effort to make the direct colours approximately the same (which I'm sure they did) and to make the mode 6 artifact colours approximately the same (which doesn't seem to be the case) the colours made by combining both techniques would still almost certainly be different - it would have been prohibitively difficult to make a gate array which perfectly matched the analogue behavior of the 74LS151.

Reply 654 of 758, by Scali

User metadata
Rank l33t
Rank
l33t
NewRisingSun wrote:

The PCjr's artifact colors are most certainly not the same as the CGA's, as several games from Sierra came in special PCjr versions with modified pixel patterns.

I know, and the artifact colours of my PVC4 and Small Wonder are certainly not the same as CGA either.
That's my point. They seem to look like PCjr, based on the 8088 MPH capture I've seen.
So if there will be some test-binaries and captures for PCjr, I'd like to run these on my PVC4 and Small Wonder as well, and see what they look like.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 655 of 758, by Scali

User metadata
Rank l33t
Rank
l33t
reenigne wrote:
Scali wrote:

After all, it's just about the phase of the colorburst vs the pixels.

There's a bit more to it than that. There's the phase of the pixels (BIOS mode 6 artifact colours) and the phases of the 6 direct colours (blue, green, cyan, red, magenta and yellow).

True, but at least in textmode, the 16 colours are the same as CGA (or well, in the same ballpark as old style and new style CGA).
Anyway, bottom line is, the 8088 MPH capture on PCjr looked an awful lot like the 'wrong' colours I was getting on these two cards (they seem to be consistent between eachother, they both appear to generate the exact same 'wrong' set of colours, which basically looked like hue shift of however many degrees compared to CGA).

reenigne wrote:

and to make the mode 6 artifact colours approximately the same (which doesn't seem to be the case)

One of them does, the other does not.
I noticed some other oddities, such as the fact that colorburst can not be enabled at all in 80-column textmode on one of the cards. I guess that was an extra safeguard to ensure readability and stability of the image on composite output. Means the high-colour modes of 8088 MPH don't work though.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 656 of 758, by kazblox

User metadata
Rank Newbie
Rank
Newbie

MAJOR 3-MONTH NECROBUMP, but has there been any minor or major progress since last post in this thread?

Great Hierophant wrote:

So which is more likely to happen first? Proper MC6845 emulation or Tandy/PCjr. composite color implementation?

Voting for proper MC6845 emulation. I'd love to see it happen later this year, and I know reenigne has upcoming plans... Heh heh.

What exactly does the DOSBOX MC6845 emulation miss that requires 8088MPH to work? Proper scanline emulation?

Reply 657 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
kazblox wrote:

MAJOR 3-MONTH NECROBUMP, but has there been any minor or major progress since last post in this thread?

Unfortunately not. I do indeed have plans, but this hasn't been high on the list lately. Actually in the last few days I picked up the project of building the device I need to gather the data for making a cycle-exact 8088 emulator (after it's been idle for 3 years or so). I managed to flash the device with a bootloader, and was able to run a simple program on the microcontroller clocked by the XT's 14.318MHz crystal. Just a bit more programming, and I should be able to gather execution traces of the 8088 and ISA bus in action.

kazblox wrote:

Voting for proper MC6845 emulation. I'd love to see it happen later this year, and I know reenigne has upcoming plans... Heh heh.

No promises, but I'll see what I can do.

kazblox wrote:

What exactly does the DOSBOX MC6845 emulation miss that requires 8088MPH to work? Proper scanline emulation?

On real hardware, there are essentially two things keeping track of the position of the raster beam. There's the CRT itself (and, in particular, the phases of the horizontal and vertical oscillators) and the counters in the CRTC. In the current DOSBox implemention, these two things are conflated, and the "virtual CRT beam" is fixed to be what the CRTC's idea of what the beam position should be.

Several of the effects in 8088 MPH reprogram the CRTC several (or even >100) times per CRT frame, essentially moving some of the CRTC's state into software. This means that the CRTC's idea of the beam position and the CRT's don't agree. So DOSBox is no longer correct in assuming that the CRTC state is accurate.

So what needs to be done is to essentially emulate a CRT as well as the CRTC. I think this is likely to be a rather more invasive change than the composite colour work. I've only skimmed the surface of what's likely to be involved so far. I'm also wondering whether it might be better to implement this on top of one of the DOSBox forks that already has some more advanced CRT features. I'm thinking in particular of overscan, since overscan kind of "comes for free" with CRT emulation. Starting with SVN DOSBox might make It more difficult to eventually port the changes to the forks, and I'm not sure how likely CRT emulation would be to be accepted into SVN DOSBox anyway. Though DOSBox could definitely do with some overscan emulation for reasons other than 8088 MPH (I'm thinking in particular of the earthquake effects at the beginning of Ultima VII).

On the PCjr/Tandy composite emulation side - I did recently point Trixter towards an ebay auction for the kind of card that would be ideal for the test captures I need to make. I'm not sure if he won it or not, though.

Reply 658 of 758, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Since you previously mentioned the possibility of adding comb filtering, the title screen in Sierra Championship Boxing would greatly benefit from it. The gray road looks rather ridiculous without comb filtering. The back of the box screenshot indicates that Composite is indeed the game's intended monitor.

Reply 659 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

Since you previously mentioned the possibility of adding comb filtering, the title screen in Sierra Championship Boxing would greatly benefit from it. The gray road looks rather ridiculous without comb filtering. The back of the box screenshot indicates that Composite is indeed the game's intended monitor.

Oh, good catch! Given that PC composite shots are also on the back of the C64 box, I'm not convinced that means anything (other than "that's what whoever designed the box happened to have in the office") but there's plenty of other evidence of composite targeting in the game - lots of patterns of pixels that alternate horizontally but not vertically. There's a US flag in one of the screens that also suggests that new CGA was the target (the red stripes are much more magenta on old CGA). Given that, the presence of checkerboard dithering does strongly hint that the graphics were designed with a comb filter in mind. Interesting too that Trixter's capture device does indeed seem to do comb filtering on the black/white checkerboard pattern. Though not on the cyan/magenta checkerboard - I suspect that might also have been a solid colour on the original developers' hardware (probably a blue).