• Please review our updated Terms and Rules here

MDA, Hercules and other clones, what's the frequency, Kenneth?

Here you are:

Hum... interesting. At least it is consistent.
But what I don't get is why it gets such high values.
What machine are you running this on?
Because if your PIT is indeed running at 1.19 MHz, as it should, then that would imply that your screen is running at approximately 29 Hz.
I cannot think of any reason why my code would consistently measure 29 Hz when the display is actually 50 Hz (which it should be, if the CRTC is running at ~16 MHz, because I reprogram all the registers, which must result in ~50 Hz in that case).

And yes, I can definitely see 45 lines of text, 8 pixels high.
Is this fact so weird?

Well, in a way it is... Namely, a frame is 370 scanlines long in total, including vertical blank period. So if you have 360 visible lines, then either the CRTC doesn't actually do a full 16-scanline vertical blank... Or it doesn't disable the visible scanlines during the entire period. Which is a bit counter-intuitive, but it might be how it works.
 
Last edited:
Last edited:
So this time I've run it on two different machines.

clone 286, 12 MHz, HGC GB102:

Code:
Hercules timing - v1.0b
Graphics:
Time 0: 32225
Time 1: 41694
Time 2: 41697
Time 3: 41692
Time 4: 41696
Time 5: 41695
Time 6: 41693
Time 7: 41693
Time 8: 41695
Time 9: 41693
Text:
Time 0: 5241
Time 1: 41199
Time 2: 41198
Time 3: 41199
Time 4: 41196
Time 5: 41198
Time 6: 41196
Time 7: 41194
Time 8: 41195
Time 9: 41198

Commodore PC 20-III, onboard video in mono mode (I don't know what exactly XTAL it uses):

Code:
Hercules timing - v1.0b
Graphics:
Time 0: 16080
Time 1: 42083
Time 2: 42078
Time 3: 42071
Time 4: 42083
Time 5: 42063
Time 6: 42078
Time 7: 42060
Time 8: 42083
Time 9: 42078
Text:
Time 0: 24524
Time 1: 41589
Time 2: 41596
Time 3: 41572
Time 4: 41585
Time 5: 41596
Time 6: 41581
Time 7: 41589
Time 8: 41588
Time 9: 41572
 
Commodore PC 20-III, onboard video in mono mode (I don't know what exactly XTAL it uses):

Ah, I have that machine as well. It uses a 16.257 MHz crystal.
What's interesting is that both your machines seem to get the same kind of error (are you running some kind of drivers/TSRs perhaps, which may interfere with the measurements?).
And even though the measurements are not what I expect them to be, they are slightly different between the two machines, which would be caused by the crystal.
Anyway, I can pull out my PC20-III and test on that one. If it gets the same measurements as yours, there is still a problem in my code, and I may be able to track it down.
 
are you running some kind of drivers/TSRs perhaps, which may interfere with the measurements?
No, I tried clean boot. Using PC DOS 2000, btw.
Also tried turbo/deturbo, still no change.

BTW, I've also tried the undocumented modes on the Commodore PC:
720x360 - works fine
640x400 - wrong, only 3/4 of the scanlines are visible, as if it actually was 640x300 with no interlace
 
No, I tried clean boot. Using PC DOS 2000, btw.
Also tried turbo/deturbo, still no change.

Yes, I've hooked up my PC20-III, did a clean boot, and saw the same thing.
I know for a fact that it is running at 50 Hz, so the bug must be somewhere in my measurement code.
But now that I can reproduce it on one of my machines, I should be able to track it down.
 
Okay, I think I found the problem.
I was writing to an 'unused' port to put delays between accesses to the PIT, for compatibility with fast systems.
However the 'unused' port was not quite as 'unused' as I hoped. I picked a different port now, and that seems to have fixed the problems on the PC20-III:
https://www.dropbox.com/s/lo7p9ravnq0407n/HERCTIME.zip?dl=0
Your 286 probably had the same problem. Its chipset may be closely related to the one in the Commodore :)
 
I was writing to an 'unused' port to put delays between accesses to the PIT, for compatibility with fast systems.

Whoops, heh. I've started writing to EE instead of 4F for the same reason. On non-microchannel IBMs, 4F isn't used for anything, but I guess it might be on clones.
 
I was about to admonish you for trashing the RTC when I double-checked the ranges; RTC ends at 76h, and the only other port usage in that range appears to start at 78h. Nice info!
 
Whoops, heh. I've started writing to EE instead of 4F for the same reason. On non-microchannel IBMs, 4F isn't used for anything, but I guess it might be on clones.

Yea exactly. I was lazy, so I copy-pasted some of the timer code from somewhere else. So I used 4F. It may have been the code from the 8088 MPH loader :)
Then I looked at the code for my 8259A auto-EOI stuff, which I knew to work on the PC20-III and my 286-20 clone, and I used EE there (probably recommended by you). So I changed it, and that fixed it.
 
clone 286@12MHz, HGC GB102:

Code:
Hercules timing - v1.0c
Graphics:
Time 0: 23842
Time 1: 23839
Time 2: 23843
Time 3: 23842
Time 4: 23843
Time 5: 23840
Time 6: 23843
Time 7: 22809
Time 8: 23842
Time 9: 23842
Text:
Time 0: 24338
Time 1: 24338
Time 2: 24337
Time 3: 24338
Time 4: 24338
Time 5: 24340
Time 6: 24337
Time 7: 24337
Time 8: 24339
Time 9: 24342

Commodore PC 20-III, onboard video:

Code:
Hercules timing - v1.0c
Graphics:
Time 0: 23464
Time 1: 23465
Time 2: 23465
Time 3: 23464
Time 4: 23457
Time 5: 23465
Time 6: 23464
Time 7: 23465
Time 8: 23465
Time 9: 23453
Text:
Time 0: 23948
Time 1: 23952
Time 2: 23951
Time 3: 23951
Time 4: 23958
Time 5: 23947
Time 6: 23947
Time 7: 23959
Time 8: 23951
Time 9: 23951
 
clone 286@12MHz, HGC GB102:
...
Commodore PC 20-III, onboard video:
...

Ah thanks, that looks good. Seems like the bug is under control now.
And as we can see, the timings of the two machines vary by about 1.5%, because one uses the 16.000 MHz crystal and the other uses the 16.257 MHz crystal.
Exactly what I wanted to confirm.
I suppose the timing routine is reasonably robust now, and I might be able to use it in actual software, to get a ballpark figure for the actual machine the application is running on, rather than hardcoding some assumed rate.

Each machine may be slightly different. Crystals aren't 100% exact, and their frequency may change a bit depending on the voltage and temperature.
For CGA that's not really an issue, since the whole system is running on the same crystal. So the whole system may run slightly faster or slower than expected, but all components remain in relative sync.
With Hercules, EGA or VGA, the video card runs on its own crystal, which means the video crystal and system crystal can drift away from eachother. Even two completely identical systems may get slightly different timing, because of inaccuracies in the crystals themselves, inaccuracies in the voltage, and the operating temperature which can all change the frequency of the crystals somewhat.
Aside from that, there is no nice lowest common denominator for the two crystals, so keeping them in sync for a longer period of time is problematic anyway. The period of a pixel or a scanline is some nasty fraction of CPU/PIT cycles.
 
I'm wondering what are you planning to do that the difference between 16.000 and 16.257 is so important?
But no, I don't really want to know, as I suspect it would be a spoiler :mrgreen:
Anyway, good luck!
 
I'm wondering what are you planning to do that the difference between 16.000 and 16.257 is so important?
But no, I don't really want to know, as I suspect it would be a spoiler :mrgreen:
Anyway, good luck!

Just when emulator devs thought it was safe...? :)
 
I suspect that you could take the crystal frequency over quite a large range, owing to the construction of the standard IBM-compatible monochrome monitor.
 
I suspect that you could take the crystal frequency over quite a large range, owing to the construction of the standard IBM-compatible monochrome monitor.

Yes, I wonder if Hercules and various clones went for 16.000 MHz because it was 'close enough', but cheaper than the 16.257 MHz crystals at the time.
But in my case I'm interested in the consequences on the software-side. I'll have to have a 'safety margin' to make sure the code works on a wide variety of hardware, and am trying to get a feel of how much of a safety margin would be realistic. I don't intend to mess with the display timings themselves, so I'll probably stick to roughly 882x370 at ~50 Hz (with the pixel area being some arbitrary subset of this).
 

I gave these 6845 register settings a quick look, and my first impression is that they are not correct for an interlaced mode (eg maximum scanline is set to 2, which means 3 in total, which is not an even number, and is not compatible with interlaced mode).
That may explain why it doesn't work properly on all cards.

I will be experimenting with interlaced modes myself soon, so I might be able to come up with a setting that works better for 640x400. In theory it should work at least.
It's only 32000*8 pixels, so it will fit in a single 32K page.

Also, after studying the 720x360 mode somewhat, I noticed that what he did is basically create a 'simulated' textmode: as in, he sets up a graphics mode, but hooks his own drawing routines into all the int 10h text functions, so that as long as an application goes through int 10h, it will be able to use this textmode. Should at least work for DOS itself. It's very slow though.
 
Last edited:
I gave these 6845 register settings a quick look, and my first impression is that they are not correct for an interlaced mode (eg maximum scanline is set to 2, which means 3 in total, which is not an even number, and is not compatible with interlaced mode).
That may explain why it doesn't work properly on all cards.

I was right, and wrong, at the same time.
The value is not correct for an MC6845. However, I now have a real Hercules GB102 card, and it has a HD6845 (as do all images I've seen of Hercules cards online. So chances are that the code was written for and tested on the HD6845).
The HD6845 datasheet differs from the MC6845 in a few crucial places. Most notably the maximum scanline value.
On MC6845 you always program it to N-1 rows. On HD6845, you need to program it to N-2 rows for the ISAV mode. This explains why it was set to 2 instead of 3. And I verified that this works on the GB102 (and setting it to 3 does not).

So my theory is that on the cards where this mode fails, you will not find a HD6845, but some other chip, with slightly different behaviour.
If it is an MC6845 or compatible, changing max scanline from 2 to 3 should fix it.
 
Back
Top