SoftCat wrote on 2024-09-23, 00:18:

I would like to suggest the following non-standard modes for EGA and CGA video adapters. I am also interested in how MartyPC wil […]
Show full quote

I would like to suggest the following non-standard modes for EGA and CGA video adapters. I am also interested in how MartyPC will match real video adapters. There are several variants in the archive. Unfortunately, I cannot run MartyPC under Windows 7 and I do not have real CGA and EGA video adapters.
1) 768x200 16 colors for EGA;
2) 720x350 16 colors for EGA;
3) 720x182 2 colors for CGA.

MartyPC doesn't have a fixed set of video modes. It should support anything you can program into the CRTC that is compatible with the card's dot clock. Several scenes in Area 5150 have an effective resolution of 768x235 on CGA.

GloriousCow wrote on 2024-09-23, 03:09:

MartyPC doesn't have a fixed set of video modes. It should support anything you can program into the CRTC that is compatible with the card's dot clock. Several scenes in Area 5150 have an effective resolution of 768x235 on CGA.

This is all clear. But I think it is difficult to emulate a breakdown of synchronization on a real monitor. These are physical characteristics of the monitor. Is the 768x235 mode for CGA there in Area 5150 text? Could you write what the CRTC register values ​​are there? In general, according to my calculations, 248 visible lines can be made on CGA. But, of course, in graphic modes there will not be enough video memory for this even with 640 columns.

SoftCat wrote on 2024-09-23, 11:35:

GloriousCow wrote on 2024-09-23, 03:09:

MartyPC doesn't have a fixed set of video modes. It should support anything you can program into the CRTC that is compatible with the card's dot clock. Several scenes in Area 5150 have an effective resolution of 768x235 on CGA.

This is all clear. But I think it is difficult to emulate a breakdown of synchronization on a real monitor. These are physical characteristics of the monitor. Is the 768x235 mode for CGA there in Area 5150 text? Could you write what the CRTC register values ​​are there? In general, according to my calculations, 248 visible lines can be made on CGA. But, of course, in graphic modes there will not be enough video memory for this even with 640 columns.

It's difficult as the effects are using frame restart, so the vertical total is not what you'd think it would be.
R0: 113
R1: 96
R2: 98
are the horizontal parameters

GloriousCow wrote on 2024-09-23, 13:22:

It's difficult as the effects are using frame restart, so the vertical total is not what you'd think it would be. R0: 113 R1: 96 […]
Show full quote

It's difficult as the effects are using frame restart, so the vertical total is not what you'd think it would be.
R0: 113
R1: 96
R2: 98
are the horizontal parameters

Thank you for the information! And is there 10 in R3 as usual?

SoftCat wrote on 2024-09-23, 14:03:

Thank you for the information! And is there 10 in R3 as usual?

15, actually.

GloriousCow wrote on 2024-09-23, 14:06:

15, actually.

Yes, 114 - 98 = 16. That is, it seems that a number no greater than 16/2 = 8 should be loaded into R3.

SoftCat wrote on 2024-09-23, 14:09:

GloriousCow wrote on 2024-09-23, 14:06:

15, actually.

Yes, 114 - 98 = 16. That is, it seems that a number no greater than 16/2 = 8 should be loaded into R3.

Why divide by two?

GloriousCow wrote on 2024-09-23, 14:31:

Why divide by two?

I was guided by this document. The table is on page 17 (in PDF page 21). Is there a mistake in the document?
https://minuszerodegrees.net/oa/OA%20-% ... 0(CGA).pdf

SoftCat wrote on 2024-09-23, 14:38:

GloriousCow wrote on 2024-09-23, 14:31:

Why divide by two?

I was guided by this document. The table is on page 17 (in PDF page 21). Is there a mistake in the document?
https://minuszerodegrees.net/oa/OA%20-% ... 0(CGA).pdf

The table seems fine, I am just not sure where you are getting your math

GloriousCow wrote on 2024-09-23, 14:45:

The table seems fine, I am just not sure where you are getting your math

Here it says that:
hsync_width = 160 pixels (= 20 character cycles).
And in the table in register R3 the number is 10.
https://www.reenigne.org/blog/cga-why-the-80- … olor-to-be-set/

R3 is the value of the hsync period in character clocks. The character clock can either be 8 or 16 hdots depending on the pixel clock selected (80 vs 40 column mode)

In 40 column mode, R3 of 10 produces a 160 dot hsync period.
In 80 column mode, R3 of 10 produces an 80 dot hsync period.
In 80 column mode, R3 of 15 produces a 120 dot hsync period.

You can see that any value of R3 should be safe in 80 column mode, as it cannot program a hsync width higher than 40 column mode uses by default.
When reenigne says that in 80 column mode hsync periods are half as wide, it's equally valid to think of them as double width in 40 column mode, which is how I tend to look at it.

So for the full-frame effects in Area 5150: 98 + 15 = 113. This fits in our scanline width of 114 (912 hdots) No need to divide anything. If you are setting up a 40 column mode, then you need to divide R0, R1, etc, to account for your characters being twice as wide, so the maximum value of R0 is now 56.

You may wonder why IBM doesn't change the value of R3 when switching between 80 and 40 column modes, if the hsync width will double in 40 column mode. On a RGBI monitor such as the IBM 5153, a PLL controls the actual hsync time, and will return the raster before the CRTC's programmed hsync width of 160 dots has fully completed. This wraps part of the hsync period around to the left of the screen. The effect of this is that 80 and 40 column modes end up lining up just fine on your screen, which you can see when you type mode 80, mode 40, mode 80, and watch the horizontal position of the C prompt.

GloriousCow wrote on 2024-09-23, 16:16:

You may wonder why IBM doesn't change the value of R3 when switching between 80 and 40 column modes, if the hsync width will double in 40 column mode. On a RGBI monitor such as the IBM 5153, a PLL controls the actual hsync time, and will return the raster before the CRTC's programmed hsync width of 160 dots has fully completed. This wraps part of the hsync period around to the left of the screen. The effect of this is that 80 and 40 column modes end up lining up just fine on your screen, which you can see when you type mode 80, mode 40, mode 80, and watch the horizontal position of the C prompt.

It's also helpful to keep in mind that the CRTC's horizontal sync width determines the duration of the CGA's horizontal *blanking* period, not that of the actual sync signal. As long as the CRTC's VS signal is high, CGA will blank the output, but the actual sync output is fixed by the CGA hardware to a shorter interval within the blanking period - IIRC, it lasts for 2 chars and starts either 1 or 2 chars after blanking does. So what really wraps around (as long as your parameters are somewhat sane) is the blanked-out section of the scanline.

A while ago I tried to determine the absolute maximum image width that a CGA plus 5153 could theoretically display, without any part of the image either getting blanked or 'folding over'. Problem was, even when you know exactly how long the horizontal retrace physically takes on the 5153, you'd still have to determine the exact phase/timing relationship between the sync signal and the actual retrace operation... and the PLL mechanism makes it rather difficult to get a real deterministic answer.

VileR wrote on 2024-09-23, 16:37:

It's also helpful to keep in mind that the CRTC's horizontal sync width determines the duration of the CGA's horizontal *blanking* period, not that of the actual sync signal. As long as the CRTC's VS signal is high, CGA will blank the output, but the actual sync output is fixed by the CGA hardware to a shorter interval within the blanking period - IIRC, it lasts for 2 chars and starts either 1 or 2 chars after blanking does. So what really wraps around (as long as your parameters are somewhat sane) is the blanked-out section of the scanline.

Good points. When I did my bus capture of Area 5150, I pulled the sync signals off the 6845 directly instead of putting probes up the CGA's DE-9 connector, because I suspected the card might do some mucking with those outputs.

In other news, the new disk stuff is going well. I don't know if I'll get a release out by the end of the month, there's just been a ton to do for a complete disk library that supports all disk operations, on both bitstream and sector-based level images.

I've implemented saving for the first few formats - you can now write your images as PRI and 86F. I was able to use this write capability to make some PROLOK-protected 86F disk images, which will be supported in 86Box 4.3 (there were some bugs with surface description handling - if you use them in an earlier version, they will erase their protection fingerprints).

Yesterday I implemented track formatting. Besides just being generally required for full emulation of the FDC, it also now lets you create a pristine, formatted bitstream image within MartyPC of a specified standard size. Complete with a custom bootsector based of C H Hockstaetter's ubiquitous code.

Maybe I should commission VileR for custom ANSI cow art...

Thank you very much for the detailed explanations!
It turns out that in the 96x** Area 5150 text mode, the horizontal blanking is 5 character cycles longer than in the standard 80x25 text mode.

And what is the maximum resolution that can be made on EGA and VGA (not SVGA)?
On SVGA, the bits in the 3C2h register corresponding to the pixel clock and sync pulse polarities are generally locked. And on different SVGA, they are unlocked differently.

I know how to make 80 colors on CGA IRGB output.

SoftCat wrote on 2024-09-24, 14:06:

I know how to make 80 colors on CGA IRGB output.

Do tell...

GloriousCow wrote on 2024-09-25, 01:56:

SoftCat wrote on 2024-09-24, 14:06:

I know how to make 80 colors on CGA IRGB output.

Do tell...

We will alternate two colors (i1, r1, g1, b1) and (i2, r2, g2, b2) every frame. Then:
(I, R, G, B) = (i1, r1, g1, b1) + (i2, r2, g2, b2).
Strictly speaking, we need a coefficient of 1/2. But we will omit it for convenience.
Each of the numbers I, R, G, B can take 3 values: 0, 1 and 2. Thus, for (I, R, G, B) we get 3^4 = 81 combinations. Note that two combinations (2, 0, 0, 0) and (0, 1, 1, 1) give the same gray color. Therefore, 80 combinations remain.

SoftCat wrote on 2024-09-25, 12:34:

We will alternate two colors (i1, r1, g1, b1) and (i2, r2, g2, b2) every frame. Then: (I, R, G, B) = (i1, r1, g1, b1) + (i2, r2, […]
Show full quote

GloriousCow wrote on 2024-09-25, 01:56:

SoftCat wrote on 2024-09-24, 14:06:

I know how to make 80 colors on CGA IRGB output.

Do tell...

We will alternate two colors (i1, r1, g1, b1) and (i2, r2, g2, b2) every frame. Then:
(I, R, G, B) = (i1, r1, g1, b1) + (i2, r2, g2, b2).
Strictly speaking, we need a coefficient of 1/2. But we will omit it for convenience.
Each of the numbers I, R, G, B can take 3 values: 0, 1 and 2. Thus, for (I, R, G, B) we get 3^4 = 81 combinations. Note that two combinations (2, 0, 0, 0) and (0, 1, 1, 1) give the same gray color. Therefore, 80 combinations remain.

Ah, sort of a temporal trick. The problem is switching a full screen of colors that fast. Might be easier on the EGA, since you have enough memory to page-flip. If you come up with a demo, let me know!

GloriousCow wrote on 2024-09-25, 14:15:

Ah, sort of a temporal trick. The problem is switching a full screen of colors that fast. Might be easier on the EGA, since you have enough memory to page-flip. If you come up with a demo, let me know!

Ok, I'll let you know if I do anything.
The Motorola 6845 datasheet says that the horizontal sync pulse (blanking pulse) width is from 0 to 15 character cycles. But reenigne claims that the maximum value is 16.
https://www.reenigne.org/blog/cga-why-the-80- … olor-to-be-set/