reenigne wrote on 2025-06-14, 11:14:

Suppose you use the simple method to get an IRQ shortly after the start for display enable. You can then "step it backwards" until you find the point where you're just before the display is enabled. The total line time is 76 PIT cycles so if you set the PIT channel 0 period to 75 then each IRQ0 will happen one cycle to the left than on the line above. So you can read the status line at the start of each of those IRQ0s and then change the period to 76 when the display enable comes back as false. That gets the PIT synchronized with the CRTC (horizontally) to within 12 hdots. Then you can synchronize it vertically as well by moving it right again by one cycle so display enable comes back as true, and then waiting for display enable to come back as false (so that you know that you're at the bottom edge). Or just by counting how many times you used the period 75 IRQ0.

I see, thank you very much!

reenigne wrote on 2025-06-14, 11:14:

Suppose you use the simple method to get an IRQ shortly after the start for display enable. You can then "step it backwards" until you find the point where you're just before the display is enabled.

This will put me at the end of the horizontal blanking. Maybe it would be better to get to the beginning of the horizontal blanking?

reenigne wrote on 2025-06-14, 11:14:

Or just by counting how many times you used the period 75 IRQ0.

I don't understand this sentence. Why is there a period of 75 for vertical synchronization?

SoftCat wrote on 2025-06-14, 17:43:

This will put me at the end of the horizontal blanking. Maybe it would be better to get to the beginning of the horizontal blanking?

I think you'll find that it's slightly more complicated to do it that way, but you can certainly do so. You know how long the horizontal blanking is so you can adjust a single IRQ0 to add in that offset.

SoftCat wrote on 2025-06-14, 17:43:

I don't understand this sentence. Why is there a period of 75 for vertical synchronization?

The period of 75 gets you horizontal synchronization. But you don't know in advance how many scanlines that's going to take. If you count them, then you'll know where you are vertically as well.

reenigne wrote on 2025-06-14, 17:48:

I think you'll find that it's slightly more complicated to do it that way, but you can certainly do so. You know how long the horizontal blanking is so you can adjust a single IRQ0 to add in that offset.

You can make the period 77. So I will move to the right and find the beginning of the horizontal blanking.

reenigne wrote on 2025-06-14, 17:48:

The period of 75 gets you horizontal synchronization. But you don't know in advance how many scanlines that's going to take. If you count them, then you'll know where you are vertically as well.

Now it is clear.

If the mode is set to CGA based on the 40x25 mode, i.e. without "snow". How many bytes can I transfer to the video RAM using "rep movsw" in 1/60 of a second?

4148 per frame. Or 4266 with DRAM refresh disabled (115.2 hdots per iteration and 112 hdots per iteration respectively). The answer is the same no matter what the video mode is (the CGA wait states are not dependent on mode).

reenigne wrote on 2025-06-16, 13:04:

4148 per frame. Or 4266 with DRAM refresh disabled (115.2 hdots per iteration and 112 hdots per iteration respectively). The answer is the same no matter what the video mode is (the CGA wait states are not dependent on mode).

Thank you very much for your answer!
I understand that the answer does not depend on the mode. But in 80x25-based modes I have much less time (due to "snow") to update the frame than 1/60 of a second.

How many bytes can be read from a hard drive on a PC-XT in 1/24 second?

SoftCat wrote on 2025-06-16, 17:23:

How many bytes can be read from a hard drive on a PC-XT in 1/24 second?

I don't have a period hard drive to test, but according to https://trixter.oldskool.org/2014/06/19/8088- … -mortem-part-1/ "most hard drives of the era operate at roughly 90KB/s" so about 3840.

reenigne wrote on 2025-06-17, 13:05:

I don't have a period hard drive to test, but according to https://trixter.oldskool.org/2014/06/19/8088- … -mortem-part-1/ "most hard drives of the era operate at roughly 90KB/s" so about 3840.

Thank you very much!
The article is exactly what I need. It would be good to master the non-composite mode 160x200 with attribute conflict.

SoftCat wrote on 2025-06-17, 17:11:

Thank you very much!
The article is exactly what I need. It would be good to master the non-composite mode 160x200 with attribute conflict.

You're welcome! I thought it sounded like what you were trying to do... The author (Trixter) is MobyGamer on here and I'm sure he'd be happy to answer questions about modifying 8088 Domination for this mode. It seems like it would just be a matter of modifying the video converter to generate the code in the right format, and integrating the playback code to do the necessary CRTC writes.

reenigne wrote on 2025-06-17, 17:37:

You're welcome! I thought it sounded like what you were trying to do... The author (Trixter) is MobyGamer on here and I'm sure he'd be happy to answer questions about modifying 8088 Domination for this mode. It seems like it would just be a matter of modifying the video converter to generate the code in the right format, and integrating the playback code to do the necessary CRTC writes.

I see, thank you very much!

Is it possible to make 127 visible lines in the first area (with R9 = 0) on CGA? That is, like this: R4 = 126, R5 = 0, R6 = 127, R7 = 0. Will the vertical sync pulse start from the 128th line with R7 = 0? Or is the maximum number of visible lines in any area (with R9 = 0) equal to 126? That is, like this: R4 = 125, R5 = 0, R6 = 126, R7 = 127.

SoftCat wrote on 2025-06-20, 15:33:

Is it possible to make 127 visible lines in the first area (with R9 = 0) on CGA? That is, like this: R4 = 126, R5 = 0, R6 = 127, R7 = 0. Will the vertical sync pulse start from the 128th line with R7 = 0?

I'd have thought the vertical sync pulse would start at scanline 0 in that case. Though the case of R7<R6 might do different things on different CRTC variants. But if you wanted 127 visible lines you could set R7 = 127 (and do the sync pulse in the second CRTC frame). That should work fine I think - you just won't get a vsync pulse at all if R7>R4. 8088 MPH and Area 5150 used that behaviour.

SoftCat wrote on 2025-06-20, 15:33:

Or is the maximum number of visible lines in any area (with R9 = 0) equal to 126? That is, like this: R4 = 125, R5 = 0, R6 = 126, R7 = 127.

Do you have a reason to think that R4 =126, R5 = 0, R6 = 127, R7 = 127 wouldn't work?

reenigne wrote on 2025-06-20, 18:48:

Do you have a reason to think that R4 =126, R5 = 0, R6 = 127, R7 = 127 wouldn't work?

Thank you for your answer!
I have no reason to believe so. Although, in terms of meaning, the vertical sync pulse overlaps the last (in the first CRTC frame) 127th line. But if the demos worked normally, then everything is fine.

SoftCat wrote on 2025-06-20, 23:04:

reenigne wrote on 2025-06-20, 18:48:

Do you have a reason to think that R4 =126, R5 = 0, R6 = 127, R7 = 127 wouldn't work?

Thank you for your answer!
I have no reason to believe so. Although, in terms of meaning, the vertical sync pulse overlaps the last (in the first CRTC frame) 127th line. But if the demos worked normally, then everything is fine.

It wouldn't overlap - R4=126 means there are 127 rows, numbered 0-126 inclusive. R7=127 is outside this range, so there would be no vertical sync pulse at all.

reenigne wrote on 2025-06-21, 10:38:

It wouldn't overlap - R4=126 means there are 127 rows, numbered 0-126 inclusive. R7=127 is outside this range, so there would be no vertical sync pulse at all.

I see, thank you. Yes, I was wrong.

Then, maybe on some CGA video cards, there will be 128 lines like this: R4 = 127, R5 = 0, R6 = 0, R7 = 0, R9 = 0.

And I'm also wondering if anyone has tried writing "forbidden" combinations to port 0x3d8, for example the number 0x19? Maybe it will be possible to make the symbol width 4 dots? 😀 But the most important thing is not to break anything during such experiments.

SoftCat wrote on 2025-06-21, 12:15:

Then, maybe on some CGA video cards, there will be 128 lines like this: R4 = 127, R5 = 0, R6 = 0, R7 = 0, R9 = 0.

Well, I would expect that the vsync pulse would overlap the top of the visible area in that case. It might depend CRTC variant though.

SoftCat wrote on 2025-06-21, 12:15:

And I'm also wondering if anyone has tried writing "forbidden" combinations to port 0x3d8, for example the number 0x19? Maybe it will be possible to make the symbol width 4 dots? 😀 But the most important thing is not to break anything during such experiments.

I have tried this, and wrote about it here: https://www.reenigne.org/blog/crtc-emulation-for-mess/ (search for "improper"). CGAArt has support for these modes so you can see what they look like. I might use one of them for a demo effect sometime.

reenigne wrote on 2025-06-21, 12:31:

I have tried this, and wrote about it here: https://www.reenigne.org/blog/crtc-emulation-for-mess/ (search for "improper"). CGAArt has support for these modes so you can see what they look like. I might use one of them for a demo effect sometime.

Very interesting article, thank you very much!