PDA

View Full Version : MDA, Hercules and other clones, what's the frequency, Kenneth?



Scali
April 25th, 2016, 02:59 AM
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):


/* 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).

Gabucino
April 25th, 2016, 04:38 AM
My IBM MDA card also has a 16.257kHz crystal.

Chuck(G)
April 25th, 2016, 08:53 AM
The manuals that came with a real Hercules had a nice section on programming details.

Scali
April 25th, 2016, 10:08 AM
The manuals that came with a real Hercules had a nice section on programming details.

Sadly I have not been able to locate the manuals in PDF format so far.

Chuck(G)
April 25th, 2016, 10:40 AM
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.

Scali
April 25th, 2016, 02:02 PM
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.
30787

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

vwestlife
April 25th, 2016, 03:55 PM
This Amdek card uses a 16.000 MHz crystal:

http://www.ebay.com/itm/262385276343

Scali
April 26th, 2016, 01:00 AM
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.

Xacalite
April 26th, 2016, 08:50 AM
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

Xacalite
April 26th, 2016, 09:13 AM
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
http://ftp.freenet.de/pub/ftp.simtel.net/pub/simtelnet/msdos/screen/hi-hgc.zip - 640x400 interlaced mode, fails to work on some cards!

Chuck(G)
April 26th, 2016, 09:40 AM
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.

Xacalite
April 26th, 2016, 10:13 AM
And here's the output of HERCTIME.EXE on a genuine GB102


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

Scali
April 27th, 2016, 03:09 AM
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.

Scali
April 27th, 2016, 05:02 AM
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).


http://ftp.freenet.de/pub/ftp.simtel.net/pub/simtelnet/msdos/screen/hi-hgc.zip - 640x400 interlaced mode, fails to work on some cards!

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.

Xacalite
April 27th, 2016, 06:09 AM
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.

Scali
April 27th, 2016, 06:48 AM
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.

Xacalite
April 27th, 2016, 07:25 AM
OK, but the 720x360 program doesn't seem to write anything other than 0 to the upper nibble of R3:


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.

Scali
April 27th, 2016, 07:32 AM
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?

Scali
April 27th, 2016, 07:39 AM
OK, but the 720x360 program doesn't seem to write anything other than 0 to the upper nibble of R3:


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.

Xacalite
April 27th, 2016, 08:01 AM
Here you are:


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.

Scali
April 27th, 2016, 08:20 AM
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.

Xacalite
April 27th, 2016, 08:48 AM
What machine are you running this on?
Some clone with a 12 MHz 286 and TACT chipset.
Never had any timing-related issues here.

Scali
April 27th, 2016, 09:47 AM
Some clone with a 12 MHz 286 and TACT chipset.
Never had any timing-related issues here.

Oh... I may know the issue then... A 286 is very fast, and may send commands to the PIT too quickly. That might explain why the timer values didn't make much sense.
I've added some delay code which hopefully fixes that: https://www.dropbox.com/s/lo7p9ravnq0407n/HERCTIME.zip?dl=0

Xacalite
April 27th, 2016, 10:45 AM
So this time I've run it on two different machines.

clone 286, 12 MHz, HGC GB102:


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):


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

Scali
April 27th, 2016, 12:56 PM
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.

Xacalite
April 27th, 2016, 02:21 PM
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

Scali
April 27th, 2016, 02:24 PM
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.

Scali
April 27th, 2016, 02:58 PM
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 :)

Trixter
April 27th, 2016, 07:30 PM
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.

Chuck(G)
April 27th, 2016, 08:45 PM
I've used 77h for garbage writes. Haven't run into a problem yet.

Trixter
April 27th, 2016, 09:39 PM
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!

Scali
April 27th, 2016, 11:57 PM
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.

Xacalite
April 28th, 2016, 06:29 AM
clone 286@12MHz, HGC GB102:


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:


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

Scali
April 28th, 2016, 07:24 AM
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.

Xacalite
April 28th, 2016, 09:32 AM
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!

Scali
April 28th, 2016, 10:29 AM
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...? :)

Chuck(G)
April 28th, 2016, 10:54 AM
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.

Scali
April 28th, 2016, 11:18 AM
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).

Scali
May 1st, 2016, 08:24 AM
http://ftp.freenet.de/pub/ftp.simtel.net/pub/simtelnet/msdos/screen/hi-hgc.zip - 640x400 interlaced mode, fails to work on some cards!

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.

Scali
May 26th, 2016, 12:31 AM
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.

Chuck(G)
May 26th, 2016, 06:52 AM
I do warn people not to count on one 6845 being like every other. I think that the HD6845 might be closer to the MC6845*2 (what an odd way to label revisions of a chip, but there it is in the databook). You can't count on dropping a plain-Jane 6845 into an Olivetti M24 display adapter board either--it won't work.

Scali
May 26th, 2016, 07:35 AM
Well, we have seen IBM use both MC6845 and HD6845 chips on their CGA cards.
So on CGA we know that interlacing will cause problems because of this (just like setting a horizontal width of 0 caused problems: HD6845 did not support it).
I just wonder if it's the same for Hercules, or if they only ever manufactured cards with HD6845s.

Great Hierophant
May 26th, 2016, 04:21 PM
Well, we have seen IBM use both MC6845 and HD6845 chips on their CGA cards.
So on CGA we know that interlacing will cause problems because of this (just like setting a horizontal width of 0 caused problems: HD6845 did not support it).
I just wonder if it's the same for Hercules, or if they only ever manufactured cards with HD6845s.

My true Hercules card has a SY6845.

Scali
May 26th, 2016, 11:57 PM
My true Hercules card has a SY6845.

Hum, that could be bad news...
I'm not familiar with the SY6845 variation. We're probably not as lucky as it being 100% compatible with the HD6845 :)

Great Hierophant
May 27th, 2016, 05:36 AM
Hum, that could be bad news...
I'm not familiar with the SY6845 variation. We're probably not as lucky as it being 100% compatible with the HD6845 :)

If you have some safe code, as in not likely to blow out my flyback transformer, I can test it the compatibility.

Xacalite
May 29th, 2016, 02:49 PM
So I did some testing with both values of CRTC register #9, and the results are:

GB102 with HD6845:

R9=2 - as usual, 640x400 works OK, image occupies only a part of the screen, as if it was 640x200
R9=3 - 640x500 is displayed, pretty useless as data from the first bank is displayed twice

Commodore PC 20-III, probably with Paradise PVC4 without any discrete 6845:

R9=2 - as I already mentioned, looks like 640x300, only three first banks are displayed
R9=3 - 640x400 seems to work, all four banks are displayed, but... the image occupies the entire screen height! Looks like it's actually non-interlaced.

Xacalite
May 29th, 2016, 03:14 PM
One more test, this time with GB112 a.k.a. Hercules Graphics Card Plus.
It has a chip with the following markings:

AMI 8717MAP
S6845EP
PHILIPPINES

R9=2 - gets out of sync
R9=3 - 640x400 seems OK, occupying something like 640x200 part of the screen

Scali
May 30th, 2016, 06:14 AM
S6845EP

Is that the same SY-chip that Great Hierophant mentioned?


R9=2 - gets out of sync
R9=3 - 640x400 seems OK, occupying something like 640x200 part of the screen

So basically if you set R9=3 on the S6845 chip, the result is the same as setting R9=2 on the HD6845 chip.
This is what I would also expect to happen with an MC6845.
So at the very least we have established that not all Hercules cards (even real ones, not clones) use 6845-derivatives with a single behaviour. And we have established that the interlaced mode can be made to work on both the HD6845 and the S6845, as long as you use the appropriate value for R9 for the chip.

So ideally we would like to be able to detect between these two variations automatically, and choose the proper R9 value. That should be possible by enabling the mode and measuring the time between two vsyncs.
Then we have to hope that there is no third variation that we don't know about yet.

Scali
May 30th, 2016, 06:17 AM
If you have some safe code, as in not likely to blow out my flyback transformer, I can test it the compatibility.

Once I have some reasonably reliable code, I can make a binary.
I cannot make any guarantees, but it should be 'safe' for the flyback transformer, since this issue deals with the vsync interval, where the hsync interval is the dangerous one.
On the other hand, interlace mode also generates an extra half scanline, I'm not sure if that is safe.

Chuck(G)
May 30th, 2016, 10:28 AM
Let's not forget the later clone Herc cards, where the 6845 is hidden in a TQFP custom IC. I wonder how those fare?

Xacalite
May 30th, 2016, 10:31 AM
Is that the same SY-chip that Great Hierophant mentioned?
Probably not, I've checked twice and it's definitely "S", not "SY".
BTW, I've googled for HGC+, and found this: http://www.seasip.info/VintagePC/Images/hgcplus1.jpg - this one has the "HD" variant.

Xacalite
May 30th, 2016, 10:38 AM
Let's not forget the later clone Herc cards, where the 6845 is hidden in a TQFP custom IC. I wonder how those fare?
Indeed, one of them is Paradise PVC4, see a few posts up.
Another one is Winbond, can't test it right now, but I reckon I saw it working OK with the original code (R9=2), so it must contain an HD-style CRTC.

Scali
May 31st, 2016, 12:29 AM
Probably not, I've checked twice and it's definitely "S", not "SY".
BTW, I've googled for HGC+, and found this: http://www.seasip.info/VintagePC/Images/hgcplus1.jpg - this one has the "HD" variant.

Dang, there's just too many 6845 chips around... and manufacturers just didn't seem to care which one they put on!
Whatever's cheapest at the moment, I guess :)

Xacalite
May 31st, 2016, 05:57 AM
Dang, there's just too many 6845 chips around... and manufacturers just didn't seem to care which one they put on!
Whatever's cheapest at the moment, I guess :)
And why would they care?
Interlaced mode wasn't officially supported, and I don't know about any real software making use of it.
Everybody used either the native 720x348, or CGA-like 640x200 or 640x300.

Scali
May 31st, 2016, 07:41 AM
And why would they care?
Interlaced mode wasn't officially supported, and I don't know about any real software making use of it.

Well, interlace is not the only possible problem.
With 8088 MPH we ran into another compatibility issue: hsync width does not work the same on all 6845s.
There may be other issues (eg, some 6845s also allow you to use the high nibble of the hsync width register to control the vsync width. Others ignore those bits).
So it's not very smart for a manufacturer to just use incompatible chips like that. As a developer you have no guarantee that things that work on your system will behave exactly the same on another system.
This stuff is not properly documented. You don't know what types of 6845 you may encounter, you don't know what the differences from one 6845 to the next will be, and you don't know how you can detect them and/or implement workarounds for these differences.

The CGA manual literally says it uses a Motorola 6845, while in reality, this is not always the case: http://minuszerodegrees.net/oa/OA%20-%20IBM%20Color%20Graphics%20Monitor%20Adapter%20(C GA).pdf
It even seems to encourage experimenting with it:

The display adapter uses a Motorola 6845 CRT Controller device. This adapter is highly programmable with respect to raster and character parameters. Therefore, many additional modes are possible with programming of the adapter.

dr.zeissler
October 5th, 2016, 09:46 AM
Interesting Thread...THX!

dr.zeissler
October 5th, 2016, 10:38 AM
According the the pictures my Schneider EuroPC also has an "Paradise PVC4" Chip. https://www.flickr.com/photos/94839221@N05/26487754492/in/album-72157665135854734/
If it's safe I'll check HERCTIME ok?

dr.zeissler
October 5th, 2016, 12:54 PM
Second Picture ist the result of your timing program http://forum.classic-computing.de/index.php?page=Thread&postID=102790#post102790
The first one is the error message of this program https://archive.org/stream/byte-magazine-1983-12/1983_12_BYTE_08-12_Easy_Software#page/n343/mode/2up
with the TASM 1.02 from 1985 http://forum.classic-computing.de/index.php?page=Attachment&attachmentID=15895&h=577911a1062bf2d4b59bcfc1e6fc53ae35d4c906 that I am using on my Schneider EuroPC.

Do you have any idea how this error message can be eliminated?

Thx and greetings
Doc

Scali
October 6th, 2016, 12:20 AM
Do you have any idea how this error message can be eliminated?

This assembly code is just a set of macros. You need the right assembler to support these macros. They look like they're in Microsoft assembler syntax.
I don't know about TASM 1.02, that's a VERY old one. I use TASM 4.0, which can run in either Microsoft or its own 'IDEAL' mode. It should be able to assemble that code.
However, assembling that code doesn't do anything yet. It calls into an int 10h handler, which does the actual 'magic'. You need to have that int 10h handler installed first. From what I understood, you need to use something they call Graph X. Which I assume is a TSR that installs the int 10h functions. I don't have this software, have not been able to find it on the net so far.
Edit: I think I found it here: http://www.pcorner.com/list/ASSEMBLY/GRAPHX11.ZIP/INFO/
It looks like it contains the graphics routines, but you call them directly, rather than via int 10h. Which leaves me wondering where the int 10h routines would come from. There's no BIOS ROM on a Hercules as far as I know, so it does not install them automatically.
Perhaps it's the HGC.COM file... or else, perhaps you can only call these when you're in HBASIC? No idea :)
In some sources it is also called "GRAFIX" instead of "GraphX"... and here it says "BIOS Interface": https://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ahUKEwj94JOG1cXPAhVFNhoKHQOYBjcQFghBMAQ&url=https%3A%2F%2Fwww.ibiblio.org%2Fpub%2FLinux%2F X11%2Fdevel%2Fsupervga-info%2Fhercules.doc&usg=AFQjCNFInYWPnAjl9mPNQ3fnzKIOPUt-lg&bvm=bv.134495766,d.d2s

I'll check it out on my own card. Perhaps there's some BIOS functions in there after all, which would surprise me somewhat, since the INIT.ASM example I got from Hercules doesn't use BIOS, but pokes the CRTC values directly. Which afaik is what all software does.

dr.zeissler
October 6th, 2016, 11:01 AM
Ok, then I misunderstood this: https://archive.org/stream/byte-magazine-1983-12/1983_12_BYTE_08-12_Easy_Software#page/n347/mode/2up
I thought this assembler script could do all the graphics that are shown here: https://archive.org/stream/byte-magazine-1983-12/1983_12_BYTE_08-12_Easy_Software#page/n355/mode/2up

As you know I don't know anything about programming. This should be the first exercise in order to get into it with things I need (hercules-gfx). because there are no real standards and
assembler differ between each other it's a VERY hard thing to go that way, because I can't distinguish if it's an issue with the assembler or an issue of the code :(

This example was only meant as an entry. The real thing is another code that produces a starfield in cga. This code works with hgcibm, but I will "transfer" it to native hercules. I found some
parallels with the int10, so I would do experiments with it...but...this seems to be tricky...argh!

I thought hercules should be the easiest platform to start with...but I am not sure anymore, but I have that very nice machine...my first PC EVER and now 27 years later, I would like to do more than just "collecting" software for it, if you know what I mean.

You might say I'll have to go studying assembler for the next 5 years and then do it, but I do not have so much time and I do not need to know anything...I just need hgc-gfx for a ultra-lowend machine...but you will call me naive for sure :)


argh! no successes yet...frustrating.

Xacalite
October 6th, 2016, 11:13 AM
HGC isn't supported by BIOS, and it doesn't contain any BIOS extension.
But there are third-party TSRs to provide INT 10h routines for HGC, the most common is MSHERC.COM, supplied with some DOS versions, and some programs require it to be loaded in order to utilize HGC graphics mode, eg. QBasic and CheckIt.
Derive comes with HERCULES.COM, which does similar thing.
There's more such things, but vast majority of HGC software programs the I/O ports directly.

dr.zeissler
October 6th, 2016, 11:38 AM
Thx! Because I could not evaluate if this is a problem not having bios-routines for hercules-gfx, I accepted it. There are lots of programs that work on real hercules without tsr's loaded before, so it should be possible to access the chips directly.
Therefore I searched the internet for native hercules-code (e.g. byte magazine) and if it worked and there was a good description for it, I thought about changing the starfield-code to hercules. You might think "stupid naive idea" , but this was it.
I thought, look where it calls CGA, change it to HGC, look how the starfild looks, change other things that are different because of the other resolution...simple and stupid, sorry :(

if the starfield code uses bios-routines of the cga-card, then...there is it...the end...no chance for me. I thought quite simple, Starfiled CGA with HGCIBM => Starfield native in Hercules...

stupid, sorry.

Scali
October 6th, 2016, 12:24 PM
Hercules is probably the most difficult to program. Firstly, because there are no BIOS routines to set the screen mode, so you have to program the CRTC directly to even switch between graphics and text mode. And the only way to draw is to poke directly into video memory.
Secondly, because it has a very complex 4-way interleaved memory layout, and two separate pages of memory.
The VGA 320x200 256 color mode is probably the easiest to start programming.

dr.zeissler
October 6th, 2016, 12:38 PM
Thx! That answer is the deadline...argh! what a mess... I thought about one resolution only two colors...sounds easy. Bios, who needs slow Bios...(joke) but I trust you, so this is the dead end for me with 0,001% assembler knowledge... :(

dr.zeissler
October 11th, 2016, 03:16 AM
Beside the programming-thing is also the CGA-Emulation. I searched the internet for a driver-disc for the paradise pvc4 but I found nothing yet.
It would be a great upgrade if I can let out the CGA-Emulation and run CGA on Hercules by setting the CGA-Mode via software.

Scali
October 11th, 2016, 05:59 AM
You could try the second utility disk here: http://vicerveza.homeunix.net/~viric/oldcomps/commodore_pc10-3.html
It contains a utility called 'VSET.COM', which I believe is the utility to select videomode for the PVC4, very similar to the one for the ATi Small Wonder (and I wouldn't be surprised if the Small Wonder utilities worked on the PVC4 anyway).

Scali
October 11th, 2016, 11:24 AM
Well, I tried VSET.COM and AGATEST.EXE on my PC20-III, and also the ATi Graphics Solution disk. They look very similar (same menu structure, test screen seem to be the same as well)...
Sadly the CGA emulation did not work on my machine. The 132 column mode did not work either.

dr.zeissler
October 13th, 2016, 12:21 PM
VSET does not work on EuroPC with Paradise PVC4. Starting VSET and using "6. CGA-Emulation" does lead to a black screen..nothing more.
132 column leads to a flickerung picture. This tool does not seem to work, or is the wrong tool the PVC4.

konc
October 16th, 2016, 11:43 PM
...(and I wouldn't be surprised if the Small Wonder utilities worked on the PVC4 anyway).
They don't, first thing I tried when you shared the small wonder utilities again.

Scali
October 16th, 2016, 11:57 PM
VSET does not work on EuroPC with Paradise PVC4. Starting VSET and using "6. CGA-Emulation" does lead to a black screen..nothing more.
132 column leads to a flickerung picture. This tool does not seem to work, or is the wrong tool the PVC4.

Yea, I think these utilities are labeled incorrectly. There's also a utility for CMOS setup, which says it's for a PC40-III (which is an AT-class machine, XTs don't have CMOS).
So I wouldn't be surprised if these tools are all for a PC40-III. The PC40-III had an ATi EGA Wonder 800+ if I'm not mistaken, which might be what led to the confusion.

So well, either the PVC4 can't do CGA-on-Hercules after all... or we still need to locate the proper utility for it. Sadly I have not been able to find any PVC4 utilities at all so far.

AlexC
October 17th, 2016, 12:23 AM
So well, either the PVC4 can't do CGA-on-Hercules after all... or we still need to locate the proper utility for it. Sadly I have not been able to find any PVC4 utilities at all so far.

I came to the former conclusion after a lot of playing around with a Commodore PC10-III. It can output CGA to a CGA monitor through 9-pin TTL or composite port, OR it can output MDA/Hercules through 9-pin TTL to an MDA/Hercules monitor. It can probably output both to a multisync monitor. But it can't emulate CGA and send it to an MDA/Hercules display. It's not a Small Wonder.

marcinstopa
October 18th, 2016, 03:16 AM
I don't know if this is relevant, but MDA (or Hercules text mode) uses 350 active scan lines (25 text lines, 14 pixels character height), while Hercules graphics mode uses a resolution of 720x348 pixels. I have even seen a routine in a hardcopy program which uses the difference in frame time (or maybe counts the h-blanks) to differentiate between graphics and text mode. (Hercules registers are write-only so they can't be used for detection, and the BIOS doesn't know about graphics mode, it only knows the card is running mode 7.

Scali
October 22nd, 2016, 05:38 AM
I don't know if this is relevant, but MDA (or Hercules text mode) uses 350 active scan lines (25 text lines, 14 pixels character height), while Hercules graphics mode uses a resolution of 720x348 pixels. I have even seen a routine in a hardcopy program which uses the difference in frame time (or maybe counts the h-blanks) to differentiate between graphics and text mode. (Hercules registers are write-only so they can't be used for detection, and the BIOS doesn't know about graphics mode, it only knows the card is running mode 7.

Yup, I've heard about that as well. For some applications, it makes sense. Eg, if you want to create a TSR that can save screenshots, you'd have to detect whether the card is in graphics mode or not. Or if you make a debugger, it has to switch to textmode when a breakpoint is hit, to show its UI. Then it has to switch back when you continue running the program.
Of course, this all breaks down as soon as you use non-standard graphics modes. But the same goes for CGA/EGA/VGA as well. You just can't read back the registers.