• Please review our updated Terms and Rules here

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

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.
 
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.
 
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.
 
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.
 
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
 

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.
 
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.
 
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.
 
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.
 
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 - IBM Color Graphics Monitor Adapter (CGA).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.
 
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/i...95&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
 
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=...nAjl9mPNQ3fnzKIOPUt-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.
 
Last edited:
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.
 
Back
Top