Please dont permanently modify this unique card..there are enough others you can replace it with 😉

Also like to mention that these cheap logic analyzers are great for debugging EGA cards and you can also display the output at unusual freqencies 😉 Think you are already using one of these?
6€ MCE2VGA replacement - CGA/EGA/HGC capture with logic analyzer

mkarcher wrote on 2020-10-10, 11:50:

I guess, I just solved a part that mystery: The card just doesn't support 200 lines modes. CRF9 is set to 3 in all 200-line modes, and set to 0 in all higher-resolution mode (including the text modes with a 8x14 character cell). This most likely means the card double-scans 200-line modes as 400-line modes (with double dot clock!), and you need a multi-sync monitor like e.g. the NEC MultiSync 2A or NEC MultiSync 3D. Did you test the theory that 200-line modes run at 15,7kHz on real hardware (in that case, my proposed solution would be wrong).

Also, the 350-line EGA text modes are not IBM compatible. The ERGO 480 runs them using a 9x14 character box instead of a 8x14 character box (just like the MDA does). You would need an 18MHz clock for that to yield EGA timings. In the EGA350 text mode tables, CLKSEL=01, which would be 32.5MHz. Also the horizontal total register is 70h, which mean 114 characters, i.e. 1026 pixels. Suppose that 32.0MHz is indeed the dot clock, that would yield 31.2kHz. The vertical total is 413 lines, which yields 75.5Hz.

Wow, those are some crazy video modes, no wonder the readings from my frequency counter didn't make any sense!

Thanks for taking the time to decode the video mode table from the BIOS image, that's super helpful.

I have some replacement RAM on the way. I'll be testing this card more thoroughly once it's able to POST and should be able to confirm your timings are correct.

mkarcher wrote on 2020-10-10, 11:50:

None of these timings is any IBM standard timing, so your initial impression is right: This card does need a non-standard monitor, but it generates a nice 720x350 text mode at 75Hz, which really deserves the card the label "ergonomic".

Any ideas for how to view the output of this card? I suppose a VGA multisync plus some kind of TTL-to-analog adapter? [Do such things exist?]

But those 29khz and 23khz modes will likely be a real problem for most VGA displays...

kdr wrote on 2020-10-10, 22:58:

But those 29khz and 23khz modes will likely be a real problem for most VGA displays...

The antique Dell LCDs that have every video connection known to man from RCA Composite to VGA to HDMI usually will deal with slower than VGA refresh rates.

In a pinch
Also you can usually drive vga directly off TTL using a very simple adapter and some impedance or resistance you just end up with 8 of the 16 or 64 colors.
Many old VGA monitors have pot adjustments for h&v holds, amoung other things.

Using an old scan fixer/adjuster I was able to get a stable split screen (but readable) driving CGA directly into a fixed frequency VGA screen.
I was unable to move the phas far enough but for a test it was ok, left text started in the middle and the right text ended in the middle.
YMMV

From what I can tell most of my vga screens didn’t have enough trim to properly display CGA but from what I could tell EGA high res was fine after adjusting.

rmay635703 wrote on 2020-10-10, 23:22:

kdr wrote on 2020-10-10, 22:58:

But those 29khz and 23khz modes will likely be a real problem for most VGA displays...

From what I can tell most of my vga screens didn’t have enough trim to properly display CGA but from what I could tell EGA high res was fine after adjusting.

I believe that it worked fine for you, but I think this is not a given thing for any monitor. Contrary to popular belief, it's not too high horizontal frequency that might kill monitors, but too low horizontal frequency. The flyback transformer is "filled with energy" during the scanline, and that energy is released to pull the beam back during horizontal retrace. There is only so much energy a flyback transformer can take (until "the core is saturated", as engineers say). If you offer even more energy, the transformer current will no longer rise slowly, but it will start to rise very quickly, beyond the limits of the horizontal stage design. This might burn the primary windings in the flyback transformer and the horizontal output transistor. Multi-Sync monitors use different techniques to avoid this problem, e.g. by reducing the operating voltage of the horizontal output stage or electronically switching components that adapt the stage to lower voltages.

Monitors with their own horizontal oscillator (which is standard, but not the case for the original MDA monitor) have that oscillator tuned so that you can be sure the monitor does not sync on frequencies that can damage the monitor. The adjustment inside the monitor is not just meant to adjust the monitor electronics to different scan rates, but primarily to be able to cancel component variation, so it reliably syncs on the design range. Thus if you tune the monitor down to lower frequencies, you might override the protection against too low scan rates.

mkarcher wrote on 2020-10-11, 06:25:

rmay635703 wrote on 2020-10-10, 23:22:

kdr wrote on 2020-10-10, 22:58:

But those 29khz and 23khz modes will likely be a real problem for most VGA displays...

From what I can tell most of my vga screens didn’t have enough trim to properly display CGA but from what I could tell EGA high res was fine after adjusting.

Thus if you tune the monitor down to lower frequencies, you might override the protection against too low scan rates.

I won’t argue that you might destroy a screen but vga/svga CRTs (yet) aren’t exactly valuable, 1997-2008 I had a free unlimited supply of blemished /old or electronically damaged/dim/marginal screens. I would usually fix them quickly and sell off cheap with computers I would also repair/upgrade quickly .

My hands have touched The internals of literally a thousand screens, in that time my schenanigans like making a screen sync to old TTL when it wasn’t supposed to never “failed “ anything but then again I didn’t leave them run in that state weeks or months either.

If any were damaged by me I couldn’t tell, Perhaps most were still over engineered,
the biggest Bain of my existence was when screens completely lacked Pot adjustment, since usually they were in my hands for being dim, wrong geometry, bad color adjustment. Given the sheer number I rarely had time to do anything “hard” to make a screen presentable And would put them in the bad stack.

YMMV

Okay, time for a quick update!

The replacement RAM (TMS4464-10NL) arrived today, so I removed the bad RAM chip from the ERGO480 and soldered in an 18-pin socket in its place. After installing a new RAM chip in the socket, the card is finally able to POST without error.

With the switches set to SW1:4=OFF:ON:ON:ON, the expected value (0x01) is stored in the low nibble of 0000:0488 (the INFO_3 byte of the BIOS data area). I would expect this switch setting to mean "MDA is primary display, EGA configured as secondary display in 80-column 200-line colour mode". Here's what the ERGO480 says during POST:

1UNISYS EVC V 1.60
2
3   Color Graphics not allowed on Monochrome Display.

And attempts to use the MODE.COM utility to set CO40 or CO80 modes results in an error beep and the message "Invalid parameters".

The ERGO480 is currently driving a 31.24khz hsync on the video output.

What's also interesting is that the SIGMAEGA.COM utility (from a Sigma!EGA driver floppy available from archive.org) reports the exact same error message when I run it:

1C:\TOOLS>SIGMAEGA CGA ON
2SigmaEGA - (C)Copyright Sigma Designs, Inc 1986   Version 1.30+
3
4   Color Graphics not allowed on Monochrome Display.

I just wanted to say that even though I only understand what your doing at a very superficial level... thanks for sharing your journey. It’s a very interesting read.

kdr wrote on 2020-10-17, 07:18:

With the switches set to SW1:4=OFF:ON:ON:ON, the expected value (0x01) is stored in the low nibble of 0000:0488 (the INFO_3 byte […]
Show full quote

With the switches set to SW1:4=OFF:ON:ON:ON, the expected value (0x01) is stored in the low nibble of 0000:0488 (the INFO_3 byte of the BIOS data area). I would expect this switch setting to mean "MDA is primary display, EGA configured as secondary display in 80-column 200-line colour mode". Here's what the ERGO480 says during POST:

Copy code to clipboard

1UNISYS EVC V 1.60
2
3   Color Graphics not allowed on Monochrome Display.

And attempts to use the MODE.COM utility to set CO40 or CO80 modes results in an error beep and the message "Invalid parameters".

The ERGO480 is currently driving a 31.24khz hsync on the video output.

How do you obtain that message? Do you have an MDA card installed alongside the ERGO480 showing that message? Did you get a monitor wired up that syncs at 31.2 (which confirms that my examination of the mode table was correct)? Did you dump the screen buffer to a floppy and read it on a different machine?

mkarcher wrote on 2020-10-17, 11:18:

How do you obtain that message? Do you have an MDA card installed alongside the ERGO480 showing that message? Did you get a monitor wired up that syncs at 31.2 (which confirms that my examination of the mode table was correct)? Did you dump the screen buffer to a floppy and read it on a different machine?

I have an MDA card in the machine and I've also removed the BIOS ROM from the ERGO480. I hacked up the ROM image a little bit (recall that it has a bank switching scheme to cram 32K of BIOS into the 16K address space at C000-C3FF) and wrote a small TSR that reads the image into memory and "boots" it. This lets me use Turbo Debugger to investigate its behaviour, including the ability to set breakpoints and stub out any "troublesome" code. Now that the errant memory chip has been replaced, I've been able to unstub most of the code.

Anyway, since the MDA is the primary display, and the BIOS just calls INT 10h to output its POST messages, the output shows up on my MDA screen. Same thing happens at boot time if you've got both an EGA and MDA installed and the MDA is the primary: the EGA BIOS outputs its POST messages on the MDA screen. 😀

kdr wrote on 2020-10-17, 07:18:

Okay, time for a quick update! […]
Show full quote

Okay, time for a quick update!

With the switches set to SW1:4=OFF:ON:ON:ON, the expected value (0x01) is stored in the low nibble of 0000:0488 (the INFO_3 byte of the BIOS data area). I would expect this switch setting to mean "MDA is primary display, EGA configured as secondary display in 80-column 200-line colour mode". Here's what the ERGO480 says during POST:

Copy code to clipboard

1UNISYS EVC V 1.60
2
3   Color Graphics not allowed on Monochrome Display.

And attempts to use the MODE.COM utility to set CO40 or CO80 modes results in an error beep and the message "Invalid parameters".

The message actually makes sense. It means "You can not emulate CGA emulation on top of the current mode, because it is an MDA mode. If you want to enable CGA emulation, please switch to a CGA-compatible mode first". By "CGA emulation", the BIOS/SIGMAEGA mean emulated CGA register-level compatibility. So the basic questions are:

• Why does the BIOS not allow switching to color modes?
• Why does the BIOS try to enable CGA emultion?

The behaviour of MODE you cite is normal (as far as I know), if you want to switch to a mode that is not supported by the BIOS. I dimly remember that the beep is standard behaviour of the mainbaord MDA/CGA BIOS, so the first thing you need to make sure is that the EGA BIOS actually installed its INT10 handler, and that the EGA BIOS has bit 2 of 40:89 cleared. That bit indicates whether the EGA should take over monochrome modes (if set) or color modes (if clear).

To switch to mode 3 (CO80), you are supposed to (the mode utility should do that for you):

1. Set the video type switch bits at 40:10 to anything but 30h (MDA)
2. Only then call INT 10h, AX=0003

This sequence is supposed to send you into the main handler for INT 10h, AH=00 at BANK2:0984. The handler is supposed to take the code path like this: Jump at 98E: taken (no monochrome monitor attached); Jump at 9CC: taken (40:10 does not claim the MDA is supposed to be active); Jump at A07: taken (again: no monochrome monitor attached, this time reaching the conclusion that the "color card" is supposed to be active and the EGA card is the "color card", so the mode needs to be set on the EGA card. This is flagged by not incrementing [BP-2]). Jump at A2F: taken (mode number not 0F or 8F).Jump at A43: taken (go to EGA mode setting code). At that point, mode setting is not supposed to go wrong.

During loading of the EGA BIOS, port 3DA, bit 2 is probed (conditional jump at BANK1:0B01). If it is clear, some "boot time emulation" is activated by calling CE01, which waits for the boot sector of a drive to be loaded and then activate the whole emulation machinery. I suppose this is meant to be able to boot in CGA compatible mode (if the EGA runs as color card) or HGC compatible mode (if the EGA runs as b/w card) without any software support. If that code path is taken in your system, try toggling the fifth dip switch you talked about. It is plausible that "boot time emulation active" and "EGA card is secondary" are mutually exclusive choices, and that's why you get the error message on the MDA screen.

Did you set your I/O port address jumper back to 3xx?

In an IBM system EGA installation, the ROM is loaded at boot, not by a TSR. The IBM motherboard is jumpered to load the ROM directly over initializing MDA/CGA from the motherboard BIOS, even if the MDA/CGA is primary. It is the responsibility of the EGA ROM to initialize the primary display. So for your MDA, the EGA ROM will initialize the controller, and set it as active. So the ROM needs to initialize some things at boot, and that doesn't seem to be happening here.

This is not happening for some reason through your TSR? Is the mainboard BIOS handler still running? I would be tempted to put the original ROM back in and try using your MDA as primary that way. If it's a fully EGA compatible ROM, it should work. I know you get strange frequencies, but at least you know where the problem lies if you can set a CGA mode now.

mkarcher wrote on 2020-10-18, 07:20:

During loading of the EGA BIOS, port 3DA, bit 2 is probed (conditional jump at BANK1:0B01). If it is clear, some "boot time emulation" is activated by calling CE01, which waits for the boot sector of a drive to be loaded and then activate the whole emulation machinery. I suppose this is meant to be able to boot in CGA compatible mode (if the EGA runs as color card) or HGC compatible mode (if the EGA runs as b/w card) without any software support.

Yes, that must be it! SW5 is wired up to pull the light pen switch input to ground, and its status is read using 03DAh bit D2. And since this BIOS has a copy of the SIGMAEGA.COM utility, it's able to activate the emulation at boot time based on the status of SW5. I guess the idea is that if you have chosen to disable CGA emulation, you are unlikely to be needing the light pen functionality either. [Has anyone ever seen a light pen? Did any software ever use it?]

I guess it's time to try the various switch combinations and see if I can find a working configuration.

I have also confirmed a couple of things about the sequencer CLKIN. If I set CLKSEL=10 or CLKSEL=11, no clock is provided to the sequencer, and CPU accesses to display memory will hang indefinitely. I then jumpered the feature connector pin 26 (14MHZ) to pin 28 (EXT OSC) and chose CLKSEL=10, which provided a 14.318Mhz clock to the sequencer. Even with a 14Mhz dot clock, I was able to read and write the video RAM when the ISA bus was running at 10mhz in turbo mode.

Thanks for looking at the video BIOS, it's always nice to have a second set of eyes on the code!

I hacked up the SPEGASYNC video BIOS so that it can load as a TSR and edited its video mode table to use CLKSEL=10 [feature connector] for the 200-line modes. (This BIOS doesn't try to program the CRF9 register at all, so it stays at its default value of 00h=double-scan disabled.)

With a jumper across pins 26 and 28 of the feature connector, I have now got my ERGO480 card driving a standard CGA display in both text and graphics modes!

It also coexists nicely with my MDA adapter. And the best part is the ERGO480 is happy at 10Mhz bus speed, even when the sequencer is only being clocked at 14.318Mhz -- so I finally have EGA graphics in my 10Mhz turbo XT system.

Next step is to play around with the SIGMAEGA.COM utility and see how the CGA emulation is meant to work.