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

Ok, I'll let you know if I do anything. The Motorola 6845 datasheet says that the horizontal sync pulse (blanking pulse) width i […]
Show full quote

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/

Depends on how you look at it. 0-15 in the registers is mapped to 1-16, as there's no possible sync width of 0?
The only way to have a width of '0' (ie no pulse) is to move it out of horizontal total range, thus never triggering it at all.
You always need at least a width of 1 to have a pulse at all.

superfury wrote on 2024-09-25, 15:50:

Depends on how you look at it. 0-15 in the registers is mapped to 1-16, as there's no possible sync width of 0?
The only way to have a width of '0' (ie no pulse) is to move it out of horizontal total range, thus never triggering it at all.
You always need at least a width of 1 to have a pulse at all.

The datasheet says otherwise. Look at page 12.
http://bitsavers.trailing-edge.com/components … Sheets/6845.pdf

SoftCat wrote on 2024-09-25, 16:06:

superfury wrote on 2024-09-25, 15:50:

Depends on how you look at it. 0-15 in the registers is mapped to 1-16, as there's no possible sync width of 0?
The only way to have a width of '0' (ie no pulse) is to move it out of horizontal total range, thus never triggering it at all.
You always need at least a width of 1 to have a pulse at all.

The datasheet says otherwise. Look at page 12.
http://bitsavers.trailing-edge.com/components … Sheets/6845.pdf

OK. You're correct. So 1-15. And 0 is effectively the same as it being out-of-range (in which case it also doesn't trigger), like above horizontal total.

superfury wrote on 2024-09-25, 16:44:

OK. You're correct. So 1-15. And 0 is effectively the same as it being out-of-range (in which case it also doesn't trigger), like above horizontal total.

Thank you!

SoftCat wrote on 2024-09-25, 17:45:

superfury wrote on 2024-09-25, 16:44:

OK. You're correct. So 1-15. And 0 is effectively the same as it being out-of-range (in which case it also doesn't trigger), like above horizontal total.

Thank you!

I think it's because I messed too much with VGA and SVGA, where it's not programmable as 0. It's just a start address (first 8 clocks) and the first match after that (modulo) is where it'll end, isn't it? Unless of course, like CGA, it starts out-of-range.

superfury wrote on 2024-09-25, 18:19:

I think it's because I messed too much with VGA and SVGA, where it's not programmable as 0. It's just a start address (first 8 clocks) and the first match after that (modulo) is where it'll end, isn't it? Unless of course, like CGA, it starts out-of-range.

By the way, there are no zero values ​​on the old i8275 text video controller either. You need to add 1 there too.

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!

On CGA you can set the mode to 128x64 with two pages. By switching these pages every frame you can make 80 colors. If anything, I can explain everything in detail.

SoftCat wrote on 2024-09-25, 19:24:

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!

On CGA you can set the mode to 128x64 with two pages. By switching these pages every frame you can make 80 colors. If anything, I can explain everything in detail.

You could also make use of the half-cell box drawing characters, like Round 42 did. https://www.mobygames.com/game/209/round-42/
If anything, I'm just skeptical if this will actually look like unique colors, or just end up being ... sparkly.

This 'temporal dithering' effect has been demonstrated on the Tandy 1000 (which does have the VRAM to page-flip in graphics modes), so you guys can judge for yourselves:

320x200x85 Tandy 1000 TL Demo (YouTube)
Technical details: https://forum.vcfed.org/index.php?threads/tan … lor-demo.35286/

Interestingly, at one point this was considered a viable approach for video cards to implement in hardware: the Quadram Quadcolor II advertised over a hundred colors (IIRC) over RGBI, done with per-frame flickering. There was also Olivetti's E.G.C./GO329 for the M24 (AKA the AT&T PC 6300 'Display Enhancement Board'), on which you could set individual palette colors to use either checkerboard dithering or frame-based "blinking", both hardware-assisted.

Apparently Sperry made a similar video board for their HT PC, and even sold a color monitor with longer phosphor persistence to eliminate the flicker, but I could never find much info about that one.

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

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:

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!

Here I made 80 colors using page switching. 9x9 table, two colors in it are the same. Will work under DOS on: CGA, EGA, VGA and higher. The more the colors differ on the pages, the more noticeable the flickering.

SoftCat wrote on 2024-09-26, 21:33:

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

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

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!

Here I made 80 colors using page switching. 9x9 table, two colors in it are the same. Will work under DOS on: CGA, EGA, VGA and higher. The more the colors differ on the pages, the more noticeable the flickering.

Is there a formula for the results for any framerate? Perhaps for blending images for every n nanoseconds rendered (applied to the last and newly rendered frames to get the effective new frame, based on the time between the frames's start of vertical retrace, although the time varable itself might have been 2 retraces back (instead of last) instead for that to work (so you'd get the time elapsed for the last frame and current frame together and using the current pixel color channel combined with the on-screen color channel (which is effectively the last result of the calculation for said chanenl on said position)))? That might be interesting to implement (although doubling the framebuffer size required, thus the memory requirement for it as well)? Perhaps it's some kind of phosphor effect?
Interestingly, UniPCemu already renders each frame to a new buffer, with the new buffer clearing all rendered pixels to black for a new frame to be written. Perhaps the effect can be written to that cleaning routine combined with the rendering routine of new pixels? But it's probably for the cleaning routine only, since rendering pixels would need to be more optimized due to it's latency (horizontal times vertical, both with hidden rendering etc. vs just the rendered frame resized to the user's screen).

superfury wrote on 2024-09-27, 22:35:

SoftCat wrote on 2024-09-26, 21:33:

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!

Here I made 80 colors using page switching. 9x9 table, two colors in it are the same. Will work under DOS on: CGA, EGA, VGA and higher. The more the colors differ on the pages, the more noticeable the flickering.

Is there a formula for the results for any framerate? Perhaps for blending images for every n nanoseconds rendered (applied to the last and newly rendered frames to get the effective new frame, based on the time between the frames's start of vertical retrace, although the time varable itself might have been 2 retraces back (instead of last) instead for that to work (so you'd get the time elapsed for the last frame and current frame together and using the current pixel color channel combined with the on-screen color channel (which is effectively the last result of the calculation for said chanenl on said position)))? That might be interesting to implement (although doubling the framebuffer size required, thus the memory requirement for it as well)? Perhaps it's some kind of phosphor effect?
Interestingly, UniPCemu already renders each frame to a new buffer, with the new buffer clearing all rendered pixels to black for a new frame to be written. Perhaps the effect can be written to that cleaning routine combined with the rendering routine of new pixels? But it's probably for the cleaning routine only, since rendering pixels would need to be more optimized due to it's latency (horizontal times vertical, both with hidden rendering etc. vs just the rendered frame resized to the user's screen).

At frame rates up to 96 Hz, you can alternate only two close colors. In general, the formula is as follows: when alternating n arbitrary colors, you need a frame rate of 48 * n Hz. If the frame rate is between 48 * (n - 1) and 48 * n, then you can confidently alternate n - 1 arbitrary colors. And to alternate n colors at such a rate, you need to specially select close colors.

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

superfury wrote on 2024-09-27, 22:35:

SoftCat wrote on 2024-09-26, 21:33:

Here I made 80 colors using page switching. 9x9 table, two colors in it are the same. Will work under DOS on: CGA, EGA, VGA and higher. The more the colors differ on the pages, the more noticeable the flickering.

Is there a formula for the results for any framerate? Perhaps for blending images for every n nanoseconds rendered (applied to the last and newly rendered frames to get the effective new frame, based on the time between the frames's start of vertical retrace, although the time varable itself might have been 2 retraces back (instead of last) instead for that to work (so you'd get the time elapsed for the last frame and current frame together and using the current pixel color channel combined with the on-screen color channel (which is effectively the last result of the calculation for said chanenl on said position)))? That might be interesting to implement (although doubling the framebuffer size required, thus the memory requirement for it as well)? Perhaps it's some kind of phosphor effect?
Interestingly, UniPCemu already renders each frame to a new buffer, with the new buffer clearing all rendered pixels to black for a new frame to be written. Perhaps the effect can be written to that cleaning routine combined with the rendering routine of new pixels? But it's probably for the cleaning routine only, since rendering pixels would need to be more optimized due to it's latency (horizontal times vertical, both with hidden rendering etc. vs just the rendered frame resized to the user's screen).

At frame rates up to 96 Hz, you can alternate only two close colors. In general, the formula is as follows: when alternating n arbitrary colors, you need a frame rate of 48 * n Hz. If the frame rate is between 48 * (n - 1) and 48 * n, then you can confidently alternate n - 1 arbitrary colors. And to alternate n colors at such a rate, you need to specially select close colors.

What I mean is, say you've gotten the RGB values of both the old and new color, and the time they each are present on the screen (say frame 1 for 1/48th second and frame 2 for 1/48th second. Those two values (in nanoseconds for example) can vary, depending on the used framerate and when the last frame was rendered).

Is there a way, for example if you take the red channel of the first and second image and include the time it both channel values were on the screen, say, frame 0 (previous result of the calculation frame 0 1234+5678ns ago strength at 33h, frame 1 1234ns present red channel strength at 22h(256 different strengths, 0-based), frame 2 5678ns present red channel strength at 33h. Can you calculate the new channel strength to use? If so, what would said formula be?
That way you'd create some kind of feedback loop (if I'm using the right term) of basically a FIFO with taps or something like that, with the last pixels channel value flowing inside the input with timestamps (how long they were active) and the output being the newly processed pixel output in some way, using the formula? The newly generated pixel would change according to time and the last 2 pixels time on-screen etc. It would effectively be some kind of phosphor effect, lasting for 2 frames?

Edit: Maybe i'm wording it incorrectly:
The last result is in the last rendered frame (this will contain the result as well, when written back from the calculation).
The 2 most recent frames are saved as inputs as well, with their respective time this was on-screen (for the last frame till the current frame).

Is there a way to calculate the newly R/G/B result based on that input? I imagined some kind of FIFO, where the most recent and previous frames are moved in a FIFO-like way (new frame rendered makes previous frame what's currently present, the current frame becomes the new frame rendered. The delta time becomes the time since the last frame. The result frame is made from the data combined (R from frame 1, R from frame 2 and delta time (nanoseconds for example) since frame 1).

superfury wrote on 2024-09-27, 23:53:

What I mean is, say you've gotten the RGB values of both the old and new color, and the time they each are present on the screen […]
Show full quote

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

superfury wrote on 2024-09-27, 22:35:

Is there a formula for the results for any framerate? Perhaps for blending images for every n nanoseconds rendered (applied to the last and newly rendered frames to get the effective new frame, based on the time between the frames's start of vertical retrace, although the time varable itself might have been 2 retraces back (instead of last) instead for that to work (so you'd get the time elapsed for the last frame and current frame together and using the current pixel color channel combined with the on-screen color channel (which is effectively the last result of the calculation for said chanenl on said position)))? That might be interesting to implement (although doubling the framebuffer size required, thus the memory requirement for it as well)? Perhaps it's some kind of phosphor effect?
Interestingly, UniPCemu already renders each frame to a new buffer, with the new buffer clearing all rendered pixels to black for a new frame to be written. Perhaps the effect can be written to that cleaning routine combined with the rendering routine of new pixels? But it's probably for the cleaning routine only, since rendering pixels would need to be more optimized due to it's latency (horizontal times vertical, both with hidden rendering etc. vs just the rendered frame resized to the user's screen).

At frame rates up to 96 Hz, you can alternate only two close colors. In general, the formula is as follows: when alternating n arbitrary colors, you need a frame rate of 48 * n Hz. If the frame rate is between 48 * (n - 1) and 48 * n, then you can confidently alternate n - 1 arbitrary colors. And to alternate n colors at such a rate, you need to specially select close colors.

What I mean is, say you've gotten the RGB values of both the old and new color, and the time they each are present on the screen (say frame 1 for 1/48th second and frame 2 for 1/48th second. Those two values (in nanoseconds for example) can vary, depending on the used framerate and when the last frame was rendered).

Is there a way, for example if you take the red channel of the first and second image and include the time it both channel values were on the screen, say, frame 0 (previous result of the calculation frame 0 1234+5678ns ago strength at 33h, frame 1 1234ns present red channel strength at 22h(256 different strengths, 0-based), frame 2 5678ns present red channel strength at 33h. Can you calculate the new channel strength to use? If so, what would said formula be?
That way you'd create some kind of feedback loop (if I'm using the right term) of basically a FIFO with taps or something like that, with the last pixels channel value flowing inside the input with timestamps (how long they were active) and the output being the newly processed pixel output in some way, using the formula? The newly generated pixel would change according to time and the last 2 pixels time on-screen etc. It would effectively be some kind of phosphor effect, lasting for 2 frames?

Edit: Maybe i'm wording it incorrectly:
The last result is in the last rendered frame (this will contain the result as well, when written back from the calculation).
The 2 most recent frames are saved as inputs as well, with their respective time this was on-screen (for the last frame till the current frame).

Is there a way to calculate the newly R/G/B result based on that input? I imagined some kind of FIFO, where the most recent and previous frames are moved in a FIFO-like way (new frame rendered makes previous frame what's currently present, the current frame becomes the new frame rendered. The delta time becomes the time since the last frame. The result frame is made from the data combined (R from frame 1, R from frame 2 and delta time (nanoseconds for example) since frame 1).

You mean multi-bit sigma delta modulation, which takes into account the accumulation error. This is a well-known algorithm that you can search for on Google. It is very similar to Floyd Steinberg's dithering, but only temporal. But this could be done if the frame rate was at least 1 kHz. With the frequencies of monitors available at the moment, you will only spoil the image.

Another option is Pulse Density Modulation and Pulse Width Modulation. But this requires a very high frame rate.

Can anyone tell me how the Vertical Total is calculated on the EGA? Am I correct in understanding that it is:
VertTotal = R6 + (R7 & 1)*256 + 2?

SoftCat wrote on 2024-09-29, 11:56:

Can anyone tell me how the Vertical Total is calculated on the EGA? Am I correct in understanding that it is:
VertTotal = R6 + (R7 & 1)*256 + 2?

Like on a VGA, except bit 5 on R7. Also no +2, that's just for horizontal total.
So:
VertTotal = R6 + (R7 & 1)*256

superfury wrote on 2024-09-29, 12:13:

Like on a VGA, except bit 5 on R7. Also no +2, that's just for horizontal total. So: VertTotal = R6 + (R7 & 1)*256 […]
Show full quote

SoftCat wrote on 2024-09-29, 11:56:

Can anyone tell me how the Vertical Total is calculated on the EGA? Am I correct in understanding that it is:
VertTotal = R6 + (R7 & 1)*256 + 2?

Like on a VGA, except bit 5 on R7. Also no +2, that's just for horizontal total.
So:
VertTotal = R6 + (R7 & 1)*256

Then on EGA for 200-line modes we get VertTotal = 4 + 256 = 260. That is, 2 lines less than on CGA.

SoftCat wrote on 2024-09-29, 12:44:

superfury wrote on 2024-09-29, 12:13:

Like on a VGA, except bit 5 on R7. Also no +2, that's just for horizontal total. So: VertTotal = R6 + (R7 & 1)*256 […]
Show full quote

SoftCat wrote on 2024-09-29, 11:56:

Can anyone tell me how the Vertical Total is calculated on the EGA? Am I correct in understanding that it is:
VertTotal = R6 + (R7 & 1)*256 + 2?

Like on a VGA, except bit 5 on R7. Also no +2, that's just for horizontal total.
So:
VertTotal = R6 + (R7 & 1)*256

Then on EGA for 200-line modes we get VertTotal = 4 + 256 = 260. That is, 2 lines less than on CGA.

Yeah, unless the program adds 2. But EGA and CGA have different register layouts, so software would add those itself if that's really needed, so R6=06h.

superfury wrote on 2024-09-29, 13:37:

SoftCat wrote on 2024-09-29, 12:44:

superfury wrote on 2024-09-29, 12:13:

Like on a VGA, except bit 5 on R7. Also no +2, that's just for horizontal total.
So:
VertTotal = R6 + (R7 & 1)*256

Then on EGA for 200-line modes we get VertTotal = 4 + 256 = 260. That is, 2 lines less than on CGA.

Yeah, unless the program adds 2. But EGA and CGA have different register layouts, so software would add those itself if that's really needed, so R6=06h.

Here on page 63 (in PDF page 68) the table shows the value R6 = 4 for all 200-line EGA modes.
https://minuszerodegrees.net/oa/OA%20-%20IBM% … s%20Adapter.pdf

I've finally plugged in fluxfox's disk visualization into MartyPC's GUI.

This allows for some cool stuff, like watching a disk get formatted (animated gif):