• Please review our updated Terms and Rules here

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

Scali

Veteran Member
Joined
Dec 13, 2014
Messages
2,024
Location
The Netherlands
I am currently playing around with Hercules graphics programming.
I don't have a real Hercules card. I do however have two clones. One is an ATi Small Wonder, the other is a Paradise PVC4 (two very similar cards, perhaps even a shared design?).
What I noticed is that these cards use a 16.257 MHz crystal. This is the same frequency as the crystal on an IBM MDA card (and on an EGA card).
However, on actual Hercules cards, you find a 16.000 MHz crystal instead.
Studying the CRTC registers for Hercules, it appears that it uses the exact same settings as IBM's MDA card in textmode. This would imply that the refresh rate of a real Hercules is slightly lower than MDA in textmode.

However, for the graphics mode, the CRTC registers appear to be programmed to the same number of scanlines, but a slightly narrower horizontal width.
That would mean that the graphics mode on a real Hercules card would be closer to the 50 Hz of textmode on a real MDA card.
For completeness, here are the values I distilled from the INIT.ASM file that comes on the Hercules Graphics Plus disks (http://minuszerodegrees.net/software/hercplus.zip):
Code:
/* 6485 controller mode data */
char hgcdat[2][12] = {
{
	/* Text mode (MDA) */
	// Each character is 9 pixels
	// Each row is 14 scanlines
	0x61,	// Horizontal total: 97 characters ('minus one', 98*9 = 882 pixels)
	0x50,	// Horizontal displayed: 80 characters (80*9 = 720 pixels)
	0x52,	// Horizontal sync position: 82 characters (82*9 = 738 pixels)
	0x0f,	// Horizontal sync width: 15 characters (15*9 = 135 pixels)
	0x19,	// Vertical total: 25 rows ('minus one': 26*14 = 364 scanlines)
	0x06,	// Vertical total adjust: 6 scanlines (364+6 = 370)
	0x19,	// Vertical displayed: 25 rows (25*14 = 350 scanlines)
	0x19,	// Vertical sync position: 25 rows (25*14 = 350 scanlines)
	0x02,	// Interlace mode: 2
	0x0d,	// Maximum scan line address: 13 scanlines ('minus one', set character height to 14)
	0x0b,	// Cursor start: 11 scanlines
	0x0c	// Cursor end: 12 scanlines
},
{
	/* Graphics mode (HGC) */
	// Each character is 2 bytes, each byte is 8 pixels
	// Each row is 4 scanlines
	0x35,	// Horizontal total: 53 characters ('minus one': 54*2*8 = 864 pixels)
	0x2d,	// Horizontal displayed: 45 characters (45*2*8 = 720 pixels)
	0x2e,	// Horizontal sync position: 46 characters (46*2*8 = 736 pixels)
	0x07,	// Horizontal sync width: 7 characters (7*2*8 = 112 pixels)
	0x5b,	// Vertical total: 91 rows ('minus one': 92*4 = 368 scanlines)
	0x02,	// Vertical total adjust: 2 scanlines (368+2 = 370)
	0x57,	// Vertical displayed: 87 rows (87*4 = 348 scanlines)
	0x57,	// Vertical sync position: 87 rows (87*4 = 348 scanlines)
	0x02,	// Interlace mode: 2
	0x03,	// Maximum scan line address: 3 scanlines ('minus one', set 'character' height to 4, to get 4-way interleaved graphics mode)
	0x00,	// Cursor start: 0 scanlines
	0x00	// Cursor end: 0 scanlines
}
};

So my first question is:
Could people with Hercules cards or other clones with MDA-compatible output check what kind of crystal is on there?
Even better would be if someone could measure the frame timings with an actual scope, both for text and graphics modes.

Second question is:
If anyone has any additional resources for programming Hercules, or anything related, I'm all ears (original manuals/reference documents etc would be very welcome).
 
Last edited:
If you can't find one, I can probably scan the one from the Herc Graphics Plus, which, other than the font ram area, operates the same way. I may well have other paper--I haven't looked yet.
 
Last edited:
I have made a simple program to check the timings by polling for the vblank signal, and recording times between two vblank signals in PIT ticks.
And indeed, in graphics mode I recorded less ticks than in text mode, which confirms that the refresh rate is slightly higher in graphics mode.
Hercules-rates.jpg

For people who want to try it on their Hercules or clone, here is the binary:
https://www.dropbox.com/s/lo7p9ravnq0407n/HERCTIME.zip?dl=0
 
I have made a simple program to check the timings by polling for the vblank signal, and recording times between two vblank signals in PIT ticks.
And indeed, in graphics mode I recorded less ticks than in text mode, which confirms that the refresh rate is slightly higher in graphics mode.

I did the maths, and it seems to check out:
Measured (ATi Small Wonder, 16.257 MHz crystal):
Graphics: ~23440 ticks
Text: ~23923 ticks

Total pixels:
Graphics: 864*370 = 319680
Text: 882*370 = 326340

319680/326340 = 0.97959183673469387755102040816327
23440/23923 = 0.97981022447017514525770179325335

So indeed, there appears to be about a 2% difference in number of pixels between the modes, translating in about 2% difference in framerate.
The only thing left to check is to see the number of ticks on a card with a 16.000 MHz crystal. We would expect the same 2% difference between modes, but overall the frametime will be slightly longer than on my card.
 
Just had a look on a bunch of cards, and the XTALs are:

original HGC (GB102) - 16 MHz
HGC+ (GB112) - 16MHz
EPSON Q205A (Hercules/CGA "dual") - 16M7C
MGP-6A, based on W86855AF - 16.000
3088D, based on TD 3088 A2 - 16.000
DT-5138, based on TD3088A - 16257
noname based on MS61C88 - 16.000
JET-MGP 3088-A2, based on TD3088A - 16.000
HI RES 4/4WPP, based on PVC4 (Hercules/CGA "dual") - 16.2570
 
Last edited:
I'd advise caution on fooling with the horizontal timing related registers on the HGC--the standard monochrome display takes its horizontal timing directly from the card (i.e. there's no oscillator in the display to sync) and you can easily toast a FBT if you goof up. I know this firsthand from experience. This is in contrast with the CGA and other adapters, where an out-of-range signal will simply fail to sync with the horizontal oscillator.

One of the issues for the 6845 is that there are various versions of the 6845 that differ slightly in register definition. So the fancy tweaks are not guaranteed to work across all cards. I noted this when replacing the 6845 on my AT&T 6300 built-in display card.
 
And here's the output of HERCTIME.EXE on a genuine GB102

Code:
Graphics:
Time 0: 26318
Time 1: 47492
Time 2: 41694
Time 3: 41694
Time 4: 41694
Time 5: 41695
Time 6: 41695
Time 7: 41695
Time 8: 41694
Time 9: 41696
Text:
Time 0: 7868
Time 1: 41196
Time 2: 41196
Time 3: 41199
Time 4: 41197
Time 5: 41198
Time 6: 41197
Time 7: 41197
Time 8: 41200
Time 9: 41196
 
And here's the output of HERCTIME.EXE on a genuine GB102

Thanks, and interesting values... These are nowhere near what I'd expect for a 50 Hz display, so there may be a bug in my code (the timer runs at ~1.19 MHz, so you'd expect about 24000 ticks per frame at 50 Hz).
At the same time, whatever it actually measures, the measurements are consistent, and the graphics timings consistently differ from the text ones.
I'll have another look over my code, and I'll see if I can spot the bug and fix it.
 
As for the programming resources, have a look at the undocumented stuff as well:
http://ftp.freenet.de/pub/ftp.simtel.net/pub/simtelnet/msdos/screen/herkules.zip - 720x360 mode

That is an interesting one.
Hercules probably chose 348 lines because it was closest to the 350 lines of MDA. But 720*348/8 = 31320 bytes.
So you can indeed fit 360 scanlines into the 32K of memory that each page has. In fact, even 364 scanlines would fit.
Similar to CGA, where 320x200 only uses 16000 bytes of the 16384 available. You can fit 4 extra scanlines in there.
I'm not entirely sure how this works in practice though, because on old 6845 CRTCs, the vblank interval is hardwired to 16 scanlines. Your screen is 370 scanlines high, so the vblank would start on scanline 354. On newer CRTCs you can program the vblank interval to be smaller, so you should be able to get more than 354 visible scanlines on screen.
I'll have to check the code to see if they try to reprogram the vblank interval (and in that case, how many Hercules cards would have a 6845 that is compatible with this feature? We know that on IBM CGAs, various 6845s were used over time, and they different slightly in behaviour).


Interlace was indeed also something I was planning to try. On CGA you won't get actual interlacing, because of the way the sync signals are wired up. Real interlaced NTSC has half a scanline difference between even and odd fields, so that the scanlines are offset a bit. On CGA, even if you enable interlacing, you still get a progressive video signal, so the scanlines of all fields overlap.
I wonder if it is different for Hercules. Then again, I am using a clone, and I know my clone supports proper interlacing, at least in some cases. Namely, it has a Hercules compatibility mode for CGA displays. In that case it generates a 400-line mode via interlacing. But when you enable the interlace flag in CGA mode, it does the same progressive scan that a real CGA card uses. I am not sure what it does on MDA, so I will have to check.
 
Last edited:
How to tell apart the old 6845 from the new one?
FWIW, I've got a few GB102 cards, and none of them has genuine Motorola 6845, they all have Hitachi chips with the following markings:

(Hitachi logo here) 6D5
HD46505SP
JAPAN
HD6845SP

720x360 seems to work fine here.
640x400 also OK, scanlines are offset from each other.
 
How to tell apart the old 6845 from the new one?

According to the datasheet here: http://www.classiccmp.org/dunfield/r/6845.pdf
The newer one is "MC6845*1" (see the description of the R3 sync width register), where '*' is the type of package (L, S or P).
So these chips would be marked MC6845L1, MC6845S1 or MC6845P1. I have only seen CGA/MDA cards with MC6845P (so the older variation), though.

The Hitachi datasheet also includes the extended functionality of the R3 register: http://www.cpcwiki.eu/imgs/c/c0/Hd6845.hitachi.pdf
So that would imply that at least your Hitachi-powered Hercules cards would support other vsync lengths than the default of 16 scanlines, by programming R3 accordingly.
 
Last edited:
OK, but the 720x360 program doesn't seem to write anything other than 0 to the upper nibble of R3:

Code:
GraphModeTiming DB 54,45,47, 7,95,0,90,90,2, 3, 0, 0,0,0          ;14 Bytes...
TextModeTiming  DB 97,80,82,15,25,6,25,25,2,13,11,12,0,0

So it should work even on the old 6845, if such were ever used in HGC cards.
 
Thanks, and interesting values... These are nowhere near what I'd expect for a 50 Hz display, so there may be a bug in my code (the timer runs at ~1.19 MHz, so you'd expect about 24000 ticks per frame at 50 Hz).
At the same time, whatever it actually measures, the measurements are consistent, and the graphics timings consistently differ from the text ones.
I'll have another look over my code, and I'll see if I can spot the bug and fix it.

I think I may have found the issue. I may have had my vertical blank wait loops backward. On my system it didn't matter at least (it shouldn't matter theoretically, as long as you consistently wait for the same point in the frame between timings, but one version may be more prone to error, since you have a smaller window).
I have updated the code at https://www.dropbox.com/s/lo7p9ravnq0407n/HERCTIME.zip?dl=0
Could you try again?
 
OK, but the 720x360 program doesn't seem to write anything other than 0 to the upper nibble of R3:

Code:
GraphModeTiming DB 54,45,47, 7,95,0,90,90,2, 3, 0, 0,0,0          ;14 Bytes...
TextModeTiming  DB 97,80,82,15,25,6,25,25,2,13,11,12,0,0

So it should work even on the old 6845, if such were ever used in HGC cards.

In that case I wonder if you actually see 360 scanlines on screen, or only 354.
 
Here you are:

Code:
Hercules timing - v1.0a
Graphics:
Time 0: 22863
Time 1: 41689
Time 2: 41694
Time 3: 41695
Time 4: 41695
Time 5: 41693
Time 6: 41694
Time 7: 41692
Time 8: 41699
Time 9: 41692
Text:
Time 0: 5242
Time 1: 41193
Time 2: 41197
Time 3: 41196
Time 4: 41196
Time 5: 41196
Time 6: 41196
Time 7: 41203
Time 8: 41190
Time 9: 41197

And yes, I can definitely see 45 lines of text, 8 pixels high.
Is this fact so weird?
Note that my monitor is NOT an IBM 5151, it's some noname thing which can sync to both 18kHz and 15kHz, so it may be more tolerant to non-standard timings.
 
Back
Top