VOGONS


MDA/CGA/EGA to VGA Converter Released!

Topic actions

Reply 181 of 341, by ibmapc

User metadata
Rank Newbie
Rank
Newbie

I'll have to do some more research on this. From the manual for the Multisync monitor;

Capture.JPG
Filename
Capture.JPG
File size
74.22 KiB
Views
1861 views
File license
Fair use/fair dealing exception

With the manual color switch off I get similar colors that I see using the converter. With it on the colors are good. So it would seem that the EGA Wonder does not work quite the same as the IBM EGA card.

Reply 182 of 341, by keropi

User metadata
Rank l33t++
Rank
l33t++

How do you make CGACAL use higher resolutions?
I will flash the latest version in a little while 😀

Edit:

I have updated to the latest version and concluded that only JIC files work for me. Remember all that hz deal with my monitor? Well after programming the JIC file I thought I'd see what the report was while playing Keen 4 and it was 640x480/60hz - not 70hz I was getting before because the SOF programming was failing for me. So that's the end of that "issue"
Now, with the new firmware I am getting some flashing pixels and rendering errors that no amount of monitor "auto-adjust" or adapter's V-PHASE value can fix. The flashing pixels are always present in varying amounts and the rendering errors don't go away. I took a small video of this, flashing pixels are easy to see , for error just look at the D letter of KEENDRMS directory, or the missing pixel on K or the G in DAGES directory.

https://www.youtube.com/watch?v=OGW9rsmITT0

Using the previous fw I was able to achieve a clean image after adjusting V-PHASE. The GREEN SCREEN + RESET button no longer works for me.

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 183 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member

what is green screen + reset ? Are you talking about the greeen monochrome emulation ? I have changed the dip on the board to be the same as MDA/hercules. So now the green screen is the dip3. Dip4 choose green/amber.

You can test an olde FW, like the first one with OSD. But What I see is problem with the SRAM/RAM, not that you unit is faulty but this blaster you have is weird. How can it only accepts .jic ? It could be that it corrupts any config that it sends, and now the RAM synthesis patterns are messed up. If even with an older FW (ask dreamblaster which one he used) that means your blaster to blame.

Reply 184 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member
ibmapc wrote:

I'll have to do some more research on this. From the manual for the Multisync monitor;

Capture.JPG

With the manual color switch off I get similar colors that I see using the converter. With it on the colors are good. So it would seem that the EGA Wonder does not work quite the same as the IBM EGA card.

check the manual about connecting it to a 5154

Reply 185 of 341, by ibmapc

User metadata
Rank Newbie
Rank
Newbie
retrocanada76 wrote:
ibmapc wrote:

I'll have to do some more research on this. From the manual for the Multisync monitor;

The attachment Capture.JPG is no longer available

With the manual color switch off I get similar colors that I see using the converter. With it on the colors are good. So it would seem that the EGA Wonder does not work quite the same as the IBM EGA card.

check the manual about connecting it to a 5154

The manual for the ATI EGA Wonder states "SW8 off will make the EGA Wonder identical to the IBM EGA in features, capabilities and limitations." But I don't find any specific info about pins for secondary colors. Later I will get my ohm meter out and see if any of the secondary color pins are shorted to ground. It's also possible that the card is showing it's age and not putting out proper signals on one or more pins. I know it does not work at all in Hercules mode although the specs say it should. Maybe it needs re-capping or has another fault. I'll try to find another EGA card to try.
EDIT, I just now found the following in the back of the manual. maybe this explains it?

Capture.JPG
Filename
Capture.JPG
File size
70.77 KiB
Views
1822 views
File license
Fair use/fair dealing exception

Reply 187 of 341, by keropi

User metadata
Rank l33t++
Rank
l33t++
retrocanada76 wrote:

If even with an older FW (ask dreamblaster which one he used) that means your blaster to blame.

I did not have these issues with the previous firmwares (maybe I didn't write it clear enough), there was always a combo that it worked and produced a clean picture. This behavior started with the very latest fw update.

About the GREEN+RESET, didn't you at some point recommended to make the screen green and hitting reset on the fpga board until the image was calibrated or something like that? Do I remember wrong?

Also about the firmware SOF JIC and whatnot, I am programming the FPGA *detached* and like I said I am using a clone BLASTER I programmer. Dreamblaster's FPGA boards are directly from Waveshare themselves AFAIK so you can rule out a cheap fpga clone or a bad board design. The only thing that remains is the cheap clone programmer device or my own fault not knowing how to open a file and press program, I want to blame the clone blaster programmer 🤣 🤣 🤣

Last edited by keropi on 2018-02-19, 15:48. Edited 1 time in total.

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 188 of 341, by ibmapc

User metadata
Rank Newbie
Rank
Newbie

sw8 closed causes the EGA Wonder to go into interlaced mode when 640x350 resolution is selected. This allows ega video to display pretty blurry on cga or composite monitors. I always have sw8 open. Checking with my meter, pin 2 is definitely NOT grounded in CGA or EGA modes. It reads 141 mV in CGA mode and drops slightly to 140 mV in EGA mode. This doesn't seem right. Pin three varies between 150 to 160 mV.

Reply 189 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member
keropi wrote:

I did not have these issues with the previous firmwares (maybe I didn't write it clear enough), there was always a combo that it worked and produced a clean picture. This behavior started with the very latest fw update.

can you try an older FW ? You can get previous versions directly from website: https://github.com/lfantoniosi/mce2vga/commits/master just click the <> button, browse to output_files folder and download the .jic file

Try the version from Feb 17 or the Jan 20 (OSD control)

Reply 191 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member

you should get a decent blaster. The .sof files are temporary, you load them and they just keeps until you press config button or turn off the board. But they are good to test without flashing the board. The .jic are the ones to be permanent in the flash ram. But if it's you blaster to blame there is nothing you can do, because it depends how the code was compiled.

Reply 192 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member

In the commit: "Calibrate the CGA colors according to CGACAL" I also changed the voltage of the pins from 2.5V to 3.3V to have voltages close to 0.7v as required to VGA. Could be it ? Try the commit previous this one.

Reply 193 of 341, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie
ibmapc wrote:

Checking with my meter, pin 2 is definitely NOT grounded in CGA or EGA modes. It reads 141 mV in CGA mode and drops slightly to 140 mV in EGA mode. This doesn't seem right. Pin three varies between 150 to 160 mV.

In the IBM EGA adapter there is a real jumper that selects if pin 2 is wired to either ground or output buffer.
But in this case, it sounds like it's not directly shorted to ground with a wire, but by keeping the TTL output buffer driving it low, perhaps by just setting the EGA palette into 4-bit RGBI mode, or keeping it low otherwise.
Well within specs for a logic zero level (output must drive below 0.4V, input must tolerate up to 0.8V). I would not worry about it.

But I see that there's no pulldown resistors on the converter DB9 connector, so if the EGA card tri-states the unused pins or it is connected to CGA card, the voltages can float at indeterminate levels as there is nothing connected to them. Nobody drives high, nobody drives low. Now, unused TTL input would most likely float at logic high level because of it's internal input structure, but as there is a CMOS chip buffering the video signals it's kind of not recommended to leave CMOS inputs floating. That's why the original IBM EGA monitor had circuitry to ignore unused color and only use 4-bit RGBI when in CGA mode. Which is also the reason that IBM EGA card outputing CGA modes can't use 64 colors.

Reply 194 of 341, by ibmapc

User metadata
Rank Newbie
Rank
Newbie
Jepael wrote:

...But I see that there's no pulldown resistors on the converter DB9 connector, so if the EGA card tri-states the unused pins or it is connected to CGA card, the voltages can float at indeterminate levels as there is nothing connected to them.

Well, I took my readings with nothing connected. So, that makes sense. I'll take a reading on pin 2 with the converter attached and active.

Reply 195 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member
Jepael wrote:

But I see that there's no pulldown resistors on the converter DB9 connector, so if the EGA card tri-states the unused pins or it is connected to CGA card, the voltages can float at indeterminate levels as there is nothing connected to them.

This shouldn't be a problem because the sync levels determines what kind of video you are dealing:

H/V Sync: POSITIVE/POSITIVE: 640x200 CGA/EGA-lores RGBI
H/V Sync: NEGATIVE/POSITIVE: 640x350 EGA-hires RRGGBB

Hercules is also NEGATIVE/POSITIVE. This is why a jumper is needed.

The FPGA will ignore the secondary colors in CGA/EGA-lores mode. But yes, in a future version I might add a pull down as well.

Reply 196 of 341, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie
retrocanada76 wrote:
This shouldn't be a problem because the sync levels determines what kind of video you are dealing: […]
Show full quote
Jepael wrote:

But I see that there's no pulldown resistors on the converter DB9 connector, so if the EGA card tri-states the unused pins or it is connected to CGA card, the voltages can float at indeterminate levels as there is nothing connected to them.

This shouldn't be a problem because the sync levels determines what kind of video you are dealing:

H/V Sync: POSITIVE/POSITIVE: 640x200 CGA/EGA-lores RGBI
H/V Sync: NEGATIVE/POSITIVE: 640x350 EGA-hires RRGGBB

Hercules is also NEGATIVE/POSITIVE. This is why a jumper is needed.

The FPGA will ignore the secondary colors in CGA/EGA-lores mode. But yes, in a future version I might add a pull down as well.

Thanks, that's good to know!

Is it better to force it than auto-detect? Auto-detecting should be possible, if there's room for it?

Normally video chips do the auto-detecting by using a reference (in this case, the 50MHz should be much larger than necessary for this), measuring reference clocks per HSync pulse.
That should get quite accurate HSync measurement if it matches EGA or MDA/Hercules mode.
Though there is a downside that Hercules can be at 16.000 or 16.257 pixel clock, so Hfreq range would be 18.1 to 18.9 kHz given all hardware/software combinations.

Also, they differ in how many HSync pulses per VSync pulse there is but not by much (Vertical Total is 366 on EGA and 370 on MDA/Herc).
Maybe that or the VSync rate being near 60Hz on EGA and near 50Hz on MDA/Hercules can be used to differentiate between modes?
Maybe it would be possible to detect between MDA text mode and Hercules graphics mode as well (they have different amount of Horizontal Total pixels per Hsync)?

(I know it might not be easy to do that on FPGA, normally the measurements are done in the video chip, and a microcontroller of some sorts is then reading those measurements and configuring the video chip for the detected mode).

Reply 197 of 341, by keropi

User metadata
Rank l33t++
Rank
l33t++
retrocanada76 wrote:

In the commit: "Calibrate the CGA colors according to CGACAL" I also changed the voltage of the pins from 2.5V to 3.3V to have voltages close to 0.7v as required to VGA. Could be it ? Try the commit previous this one.

I have tried the previous commit labeled "Experimenting the 720x480 resolution for CGA. Larger border overscan" and there are no more parasites for me.
Maybe there is the need for some more power filtering when the voltage is raised? some eletrolytic capacitor perhaps?

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 199 of 341, by retrocanada76

User metadata
Rank Member
Rank
Member
Jepael wrote:

Is it better to force it than auto-detect? Auto-detecting should be possible, if there's room for it?

It would require a lot of testing and measurements. It should be the time between the hsyncs to be measured. And then from mda to hercules it would be pratically impossible. The difference is too small. And then you have a board out of specs and the converter won't detect it.

Also there is question about colors. Many monitors have a monochrome switch, so as my converter.