SoftCat wrote on 2024-10-12, 00:00:

EGA card Gemini VC-001. Multisync monitor is not needed here at all. Look: 14318000/114 ~= 16257000/129, 14318000/912 ~= 1625700 […]
Show full quote

EGA card Gemini VC-001. Multisync monitor is not needed here at all. Look:
14318000/114 ~= 16257000/129,
14318000/912 ~= 16257000/1032.
And otherwise everything is like CGA.

if you (or anyone else) can show me evidence of this working on an IBM 5154 or other dual-frequency EGA monitor of the era i will consider it a bug, but i'd have to rethink how i handle the display field entirely. I didn't consider a 16Mhz 15KHz mode.

if you look in the screenshot, "Field: 774x364" that is currently the maximum supported resolution with the 16Mhz clock.

GloriousCow wrote on 2024-10-12, 01:22:

SoftCat wrote on 2024-10-12, 00:00:

EGA card Gemini VC-001. Multisync monitor is not needed here at all. Look: 14318000/114 ~= 16257000/129, 14318000/912 ~= 1625700 […]
Show full quote

EGA card Gemini VC-001. Multisync monitor is not needed here at all. Look:
14318000/114 ~= 16257000/129,
14318000/912 ~= 16257000/1032.
And otherwise everything is like CGA.

if you (or anyone else) can show me evidence of this working on an IBM 5154 or other dual-frequency EGA monitor of the era i will consider it a bug, but i'd have to rethink how i handle the display field entirely. I didn't consider a 16Mhz 15KHz mode.

if you look in the screenshot, "Field: 774x364" that is currently the maximum supported resolution with the 16Mhz clock.

I still think that for 640x350 mode the full raster will be 744x366, not 364. Also note that here you add 2 to VerticalTotal:
https://raw.githubusercontent.com/dbalsom/mar … debugger_01.png

SoftCat wrote on 2024-10-12, 14:50:

I still think that for 640x350 mode the full raster will be 744x366, not 364. Also note that here you add 2 to VerticalTotal:
https://raw.githubusercontent.com/dbalsom/mar … debugger_01.png

the field is somewhat of a monitor abstraction. the monitor doesn't know anything about vertical total. the field is fixed at 912*262 for the 14Mhz clock. So i'm not adding 2, they just happen to differ.
the apertures for EGA are not entirely final. I've noticed some games cut off a row of pixels or have an extra row.

The fixed display field technique worked well for CGA, but it is a lot harder to pull off for EGA and especially VGA. Although I was praised for emulating CGA overscan, what MartyPC is doing still isn't really the fundamentally correct way to do this. Now that I have a bit of experience with PLLs under my belt dealing with flux images, I think the ultimate way to go is to emulate a monitor completely, and have a PLL sync to the horizontal and vertical timings.

GloriousCow wrote on 2024-10-12, 01:22:

SoftCat wrote on 2024-10-12, 00:00:

EGA card Gemini VC-001. Multisync monitor is not needed here at all. Look: 14318000/114 ~= 16257000/129, 14318000/912 ~= 1625700 […]
Show full quote

EGA card Gemini VC-001. Multisync monitor is not needed here at all. Look:
14318000/114 ~= 16257000/129,
14318000/912 ~= 16257000/1032.
And otherwise everything is like CGA.

if you (or anyone else) can show me evidence of this working on an IBM 5154 or other dual-frequency EGA monitor of the era i will consider it a bug, but i'd have to rethink how i handle the display field entirely. I didn't consider a 16Mhz 15KHz mode.

if you look in the screenshot, "Field: 774x364" that is currently the maximum supported resolution with the 16Mhz clock.

A CRT monitor doesn't care how many columns and what pixel clock. As long as HFreq and VFreq are correct. For what reason could 16.257 MHz and 15.75 kHz mode be impossible?

SoftCat wrote on 2024-10-12, 16:21:

A CRT monitor doesn't care how many columns and what pixel clock. As long as HFreq and VFreq are correct. For what reason could 16.257 MHz and 15.75 kHz mode be impossible?

I haven't said it's impossible. I said I'd like proof that it worked on a real 5154 monitor. If it does, great.

GloriousCow wrote on 2024-10-12, 16:42:

SoftCat wrote on 2024-10-12, 16:21:

A CRT monitor doesn't care how many columns and what pixel clock. As long as HFreq and VFreq are correct. For what reason could 16.257 MHz and 15.75 kHz mode be impossible?

I haven't said it's impossible. I said I'd like proof that it worked on a real 5154 monitor. If it does, great.

Ok, I got it.
On EGA in mode 7: pixel clock 16.257 MHz, visible part 720x350 and full raster 882x368.
And in Fh mode: pixel clock 14.318 MHz, visible part 640x350 and full raster 784x368.
In general, on EGA you can set the graphic mode 720x350 and monochrome and color.
But for all these modes the monitor must support HFreq = 18.43 kHz.

SoftCat wrote on 2024-10-12, 18:12:

In general, on EGA you can set the graphic mode 720x350 and monochrome and color.
But for all these modes the monitor must support HFreq = 18.43 kHz.

Which the 5154 doesn't, as it's limited to 15.7 (for 200-line modes) or 21.8 kHz (for the 350-line mode).

JAL

jal wrote on 2024-10-12, 18:58:

SoftCat wrote on 2024-10-12, 18:12:

In general, on EGA you can set the graphic mode 720x350 and monochrome and color.
But for all these modes the monitor must support HFreq = 18.43 kHz.

Which the 5154 doesn't, as it's limited to 15.7 (for 200-line modes) or 21.8 kHz (for the 350-line mode).

JAL

Monochrome is suitable (for MDA and Hercules) or multisync monitor.

GloriousCow wrote on 2024-10-12, 16:09:

the field is somewhat of a monitor abstraction. the monitor doesn't know anything about vertical total. the field is fixed at […]
Show full quote

SoftCat wrote on 2024-10-12, 14:50:

I still think that for 640x350 mode the full raster will be 744x366, not 364. Also note that here you add 2 to VerticalTotal:
https://raw.githubusercontent.com/dbalsom/mar … debugger_01.png

the field is somewhat of a monitor abstraction. the monitor doesn't know anything about vertical total. the field is fixed at 912*262 for the 14Mhz clock. So i'm not adding 2, they just happen to differ.
the apertures for EGA are not entirely final. I've noticed some games cut off a row of pixels or have an extra row.

The fixed display field technique worked well for CGA, but it is a lot harder to pull off for EGA and especially VGA. Although I was praised for emulating CGA overscan, what MartyPC is doing still isn't really the fundamentally correct way to do this. Now that I have a bit of experience with PLLs under my belt dealing with flux images, I think the ultimate way to go is to emulate a monitor completely, and have a PLL sync to the horizontal and vertical timings.

So, it turns out that on EGA in 200-line modes there are 2 lines less than on CGA? And, accordingly, the frame rate is slightly higher?

SoftCat wrote on 2024-10-12, 19:55:

So, it turns out that on EGA in 200-line modes there are 2 lines less than on CGA? And, accordingly, the frame rate is slightly higher?

I think you're assuming I've researched EGA to the extent I have CGA. I have not. I basically hacked stuff together until Commander Keen worked. Everything about it could be completely wrong and probably is.

But it does play Commander Keen.

Once I'm out of the long slog through floppy emulation, I'll be revisiting both EGA and VGA.

GloriousCow wrote on 2024-10-12, 20:03:

I think you're assuming I've researched EGA to the extent I have CGA. I have not. I basically hacked stuff together until Comma […]
Show full quote

SoftCat wrote on 2024-10-12, 19:55:

So, it turns out that on EGA in 200-line modes there are 2 lines less than on CGA? And, accordingly, the frame rate is slightly higher?

I think you're assuming I've researched EGA to the extent I have CGA. I have not. I basically hacked stuff together until Commander Keen worked. Everything about it could be completely wrong and probably is.

But it does play Commander Keen.

Once I'm out of the long slog through floppy emulation, I'll be revisiting both EGA and VGA.

Are you doing i8272 emulation? Will it be possible to read the entire track, including intersector gaps? Will there be support for 5.25" drives with 80 tracks and a size of 720 KB?

SoftCat wrote on 2024-10-12, 20:18:

Are you doing i8272 emulation?

It's sort of a generic thing implementing the μPD765A command set at the moment. I have plans to do a HD controller, taking advantage of GLaDISK bios.

SoftCat wrote on 2024-10-12, 20:18:

Will it be possible to read the entire track, including intersector gaps?

Yes, already possible. Many copy protected titles do a Read Track command.
i have verified many different copy protection methods work, with the right images:
Formaster CopyLock
Softguard SuperLok 2 & 3
EA Interlock
Vault Prolok
XEMAG Xelok 1 & 2

SoftCat wrote on 2024-10-12, 20:18:

Will there be support for 5.25" drives with 80 tracks and a size of 720 KB?

That's a weird format. I don't see why not though. I have yet to enforce many logical or physical limitations on my disk drives, so you can do weird things like shove a 1.44MB diskette image into a 360K drive. Eventually though, each drive type will be limited to specific bitrates and cylinder counts

GloriousCow wrote on 2024-10-12, 20:29:

It's sort of a generic thing implementing the μPD765A command set at the moment. I have plans to do a HD controller, taking adv […]
Show full quote

SoftCat wrote on 2024-10-12, 20:18:

Are you doing i8272 emulation?

It's sort of a generic thing implementing the μPD765A command set at the moment. I have plans to do a HD controller, taking advantage of GLaDISK bios.

SoftCat wrote on 2024-10-12, 20:18:

Will it be possible to read the entire track, including intersector gaps?

Yes, already possible. Many copy protected titles do a Read Track command.
i have verified many different copy protection methods work, with the right images:
Formaster CopyLock
Softguard SuperLok 2 & 3
EA Interlock
Vault Prolok
XEMAG Xelok 1 & 2

SoftCat wrote on 2024-10-12, 20:18:

Will there be support for 5.25" drives with 80 tracks and a size of 720 KB?

That's a weird format. I don't see why not though. I have yet to enforce many logical or physical limitations on my disk drives, so you can do weird things like shove a 1.44MB diskette image into a 360K drive. Eventually though, each drive type will be limited to specific bitrates and cylinder counts

I see. Thank you very much for your answer!

SoftCat wrote on 2024-10-12, 20:18:

Will there be support for 5.25" drives with 80 tracks and a size of 720 KB?

Do 80-track 720KB 5.25" drives look any different to the floppy controller than 720K 3.5" drives?

mkarcher wrote on 2024-10-12, 20:48:

SoftCat wrote on 2024-10-12, 20:18:

Will there be support for 5.25" drives with 80 tracks and a size of 720 KB?

Do 80-track 720KB 5.25" drives look any different to the floppy controller than 720K 3.5" drives?

I don't know exactly. But I think that in terms of commands for the floppy controller and the contents of the service areas, they are no different. But then 5.25" 720 KB drives may not be supported by BIOS. Therefore, a driver may be needed.

Can anyone test this mode on a real IBM 5154 or other dual-frequency EGA monitor?
I would be very grateful.

GloriousCow wrote on 2024-10-12, 20:03:

I think you're assuming I've researched EGA to the extent I have CGA. I have not. I basically hacked stuff together until Comma […]
Show full quote

SoftCat wrote on 2024-10-12, 19:55:

So, it turns out that on EGA in 200-line modes there are 2 lines less than on CGA? And, accordingly, the frame rate is slightly higher?

I think you're assuming I've researched EGA to the extent I have CGA. I have not. I basically hacked stuff together until Commander Keen worked. Everything about it could be completely wrong and probably is.

But it does play Commander Keen.

Once I'm out of the long slog through floppy emulation, I'll be revisiting both EGA and VGA.

There are two generators on VGA: 25.175 MHz and 28.322 MHz. But the horizontal frequency is always the same 31.50 kHz. And also 28.322/25.175 ~= 9/8. That is, the first generator is designed for 640 columns, and the second for 720 columns. Pixel duplication is also possible, which will be 320 and 360 columns, respectively. Therefore, it probably makes sense to provide switching between 640 and 720 columns in all text and graphic modes. In graphic modes, the width of a character cycle is always 8 pixels, and in text modes with 720 columns, the width of a character can be 9 and 8 pixels. Which corresponds to 80 and 90 character columns.

I thought that 720 columns is always 80 characters, with the 8-pixel-wide characters being auto-extended?

JAL

Btw GloriousCow, saw both of your VCF talks on YouTube, enjoyed them very much. Best YouTube vids I watched in a long time 😁.

JAL

jal wrote on 2024-10-13, 16:21:

I thought that 720 columns is always 80 characters, with the 8-pixel-wide characters being auto-extended?

JAL

No, the character width in text modes on VGA is set in a register. And it can be either 8 or 9 pixels. The 9th column can be displayed in the background color or duplicate the 8th column for some characters.