I think it enables underlined characters when the low 3 bits of the attribute are 001 (see http://www.seasip.info/VintagePC/mda.html). Possibly also reverse-video for attributes 0x70, 0x78, 0xf0 and 0xf8.

If the bit is zero, text attributes are in color adapter mode (CGA,EGA,VGA text modes), the attribute byte defines character foreground/background/blinking. There is no underlining, or inverse video attributes.

If the bit is one, text attributes are in mono adapter mode (MDA text mode), the attribute byte defines if the character is dark/bright, inversed or not, underlined or not, blinking or not. There are no background/foreground attributes.

See this : http://www.seasip.info/VintagePC/mda.html#memmap

So according to your link:
Bit 1: Underline.
Bit 3: High intensity.
Bit 7: Blink

- Bit 7 is already the same as the VGA, so that behaviour is the same as the VGA(unchanged).
- High intensity can simply be mapped by the attribute registers 0x0-0xF themselves. Just map colors 0-7 to dark intensity and colors 8-F to high intensity. Should my emulation do anything with this? Also the boldness of those characters can simply be handled by the VGA's ability to handle charset A(bit set to 0) vs charset B(bit set to 1)?
- Bit 1 being 0 should disable the underline function of the VGA Underline register?

VGA Underline register sets on which character line the underlining would be if a character is underlined. In some documentations it is said it only works in monochrome emulation mode.

The underline attribute bit selects if the character in question is underlined or not.

MDA has no bolding.

I've applied the attributes according to the manual:
https://bitbucket.org/superfury/x86emu/src/c1 … ler.c?at=master

The colors still don't work correctly for some reason, perhaps a problem in the attribute registers themselves. Also the background doesn't look like it's applied, or too dark to see? Font/background text is readable and visible, but the background keeps being black during blinking for some reason? Reverse only seems to have effect on text, but not background? Is this supposed to happen?
Underline location seems to be using the wrong line (line 15 of the 14 line font)?

I've just looked at the register values in mode 7h again, I notice that the Monochrome Emulation bit (bit 1 in the Attribute Mode Control register) is 0? Is this supposed to be cleared? As far as I know it's supposed to be set in mode 7(To ensure the monochrome mode)?

So it's in color emulation mode, thus generating the wrong input?

Like ripsaw8080 said, if the BIOS says it's in colour mode then it translates mode 7 to mode 1, which seems like a very bizarre behaviour (modes 3 or 2 would make more sense, being 80-column modes) but does account for what you're seeing.

What happens if you go into mode 7 by doing "mode mono"?

Well my MS-DOS 5.0 installation doesn't have the mode command, so all I have is my debug.exe-assembled modemono.exe, which just switches to mode 7h and exits. This doesn't change anything in the application, the monochrome mode still isn't set. I've applied a little patch to the Dosbox int10 code in my emulation to enable the Attribute Controller Mode Control Register's bit 1 (Or'ing value 2 into it after the pallette is filled in mode 7h). I do notice that the application is better visible now.

I'm currently writing a little Turbo Pascal 6.0 program to print the table from the page at http://www.seasip.info/VintagePC/mda.html#memmap to compare results.

Edit: Managed to get the monochrome emulation itself properly working now(it was having the problem of reversing the mode control bit 2 instead of using it normally, thus reversing monochrome operation during color mode and color mode during monochrome mode). All attributes are properly used and shown. The only problems that are left are the underline location (set to 0x1F, thus applying to row 0x20(invisible) according to freeVGA documentation) and the colors that are used (it's currently taking colors 0, 8, 0x10 and 0x18. The display in checkit seem to be using attributes translated to 8 and 0x18(bright), thus looking a bit odd when using the EGA DAC pallette(looking at the raw DAC dump colours being a small list of 64 colors only))?

Anyone knows if this is correct?

There's also still the problem of the display itself being misaligned, as given in the screen capture at the start of the thread. Anyone knows what might be causing this? When looking at the CRTC registers it seems to be programmed like this(hexdecimal values):
Horizontal total register: 2D
End horizontal display register: 27
Start horizontal blanking register: 28
End horizontal blanking register: 90
Start horizontal retrace register: 2B
End horizontal retrace register: A0
Vertical total register: BF
Overflow register: 1F
Preset row scan register: 00
Maximum scanline register: 4F
Cursor start register: 0D
Cursor end register: 0E
Start address high register: 00
Start address low register: 00
Cursor location high register: 03
Cursor location low register: 91
Vertical retrace start register: 9C
Vertical retrace end register: 8E
Vertical display end register: 8F
Offset register: 14
Underline location register: 1F
Start vertical blanking register: 96
End vertical blanking register: B9
CRTC mode control register: A3
Line compare register: FF

The vertical timings seem fine, but the horizontal timings seem a bit low (only a bit of display before retracing etc., 351 pixels of active display to be exact as far as I can calculate (0x27 times 9 pixel width)?

Edit: Fixed some bugs that allowed the CRTC registers to be read at the disabled addresses (based on bit 0 of the Misc Output Register). The wrong values given in this post still are loaded for some reason.

I've managed to get the mode.com out of the setup disks and extract it with extract.exe, ran mode mono. Now the display looks correct. Only the mono attributes are limited again in this case.

Edit: It looks like, after executing "mode mono" and running Checkit Diagnostics, setting it to use color mode will enable colors again. Then, when running the tests everything works as expected, however reversed text isn't displayed (in non-color modes 0, 2 and 7) as reversed, but normal(/dark/bright) without reverse instead?

Edit: Just found out something strange: Correct mode 7 only works with mode mono enabled, as do all things with Mono emulation (underline, bright etc.) that it does. But in order to properly use the reverse text, color mode is needed? mode mono(Both w/ and w/o) won't use reversed backgrounds for some reason (even though it's in the attribute controller emulation itself?).

https://bitbucket.org/superfury/x86emu/src/76 … ler.c?at=master

The attribute image contains a big table for all color combination output precalculations for character row 0.

It contains four lines(16x16 pixels per item) with each line representing the 256 attribute byte inputs.

The first line contains foreground pixel, blinking indicator on.
The second line contains background pixel, blinking indicator on.
The third/fourth line contains the same as first/second line, but blinking indicator off.

The blinking indicator is flipped every ~30 frames of
rendering, at half the text cursor rate, according to VGA specs.

- Without the "mode mono" command, I end up with wrong colors during mode 7h and without underline ability. Reverse blinking is working correctly in all modes. Colors are blue on black and greenish on black in mode 7h. All other text modes work without problems. Mode 7h messes up the CRTC registers, producing the ~400 horizontal pixels display. Other modes have correct display resolutions.

- With the "mode mono" command, the menus of Checkit Diagnostics have missing background on the active item(s). All text modes end up in 80x25 characters. CRTC is functioning properly. Reverse (w/ and w/o blinking) ends up with black backgrounds. Underline works correctly with mode 7h.

Anyone can see what's going wrong here? Anyone knows the cause of this strange behaviour?

After looking at the register dumps of the mono vs not mode mono I notice:
Mode Mono sets the Monochrome emulation bit, Without calling it, the Monochrome emulation bit isn't set (thus no mono attributes are emulated, so no Underline, Reverse and Off(0,8,0x80 and 0x88) attributes.

Also Mode mono seems to lock the display to 80x25, even in the 40x25 modes (modes 0&1).

The attributes thus are almost the same, with some differences on two things:
- Color mode uses black, dark blue and some green colors, Monochrome mode uses Black, Light grey and White instead of black, dark blue and green.
- Attributes 0x70,0x78,0xF0 and 0xF8 have reversed font and background pixels between monochrome and color modes.

This can be seen by looking at the VGA_ATT.bmp files for both the mode mono and color dumps. All other things are the same. Although it only shows the status of row #0. Rows #1-13 isn't dumped yet. I'll enable that in the dumps now too.

This is the full dump of all rows:
It seems that rows 1-14 isn't used for some reason?

Edit: A little update:

I've fixed the dump to be a little more complete. Now all 32 lines are dumped instead of only scanline #0. Also the size of each pixel has been reduced from 16 pixels to 1 pixel to be more compact and lookupable.
When comparing both dumps:
- The reversed font/back in the monochrome emulation(only when "mode mono" is executed) mode is applied correctly (monochrome mode only, by setting the Monochrome Emulation bit in the Attribute Mode Control Register).
- Monochrome mode seems to set font color with attributes 0x01, 0x03, 0x81 and 0x83 on line 15. This is the underline working.

Thus that part of emulation seems to work. Then why does reverse attribute not work in the Monochrome emulation mode? It actually seems to be applied correcly according to the color dump images? Is the VGA ROM actually applying it through charset A/B or the font ROM itself?

What VGA BIOS are you using? Maybe it does not support mode 7h properly, or, maybe it sets just some registers correctly and it is enough for that VGA hardware (physical or emulated).

Why it works differently with "MODE MONO" command, it could be that after that the VGA BIOS either tries to actually control the MDA hardware, or, the VGA BIOS knows it should not handle the MDA mode so it forwards the calls to default int 10h handler. When "MODE CO80" is used, the VGA BIOS will control the VGA hardware for emulating the MDA mode.

I made some progress: all attributes now work with "mode mono", except that all odd 8x(lower nibble has no bit 3 set) attributes become background instead of foreground? When bit3=1 the characters are white/bright on black(or reversed/background/underlined as they should). Also, for some reason, every time the low nibble is 1 or 3(attributes X9 and XB) it uses underlining(even though the underline is only done when (attribute&0x77)==1 according to the code I've written according to the freeVGA documentation.

The BIOS I'm using was discussed earlier in this thread(with the signature and CRC32 checksum calculated by packing and properties of the packed file using Windows 10's zip/unzip functionality). It was one of the two signatures mentioned.

Edit: It is the following ROM mentioned by reenigne:

reenigne wrote:

6c12d745 ibmvga.rom

Edit: Could it be that either character set B isn't loaded(correctly) or is pointing to the wrong character set(empty VGA memory containing zeroes)? That would explain the characters missing when bit3=0?
Or is it a problem with the colors itself with attributes #1-7?

Edit: Found a problem that might cause incorrect character font lookup table updating: the character to be updated was taken from the address changed(plane 2 address) shifted right by 5 bits to get the character index to update. However, this would create a character number of 256+ when not updating the first character set(charset #0), which would end up not updating anything at all, no matter what the active character set A or B is. Only writes to the first character set would update the active(rendered) precalcs containing the character fonts(looked up by attribute bit 3, the character index(8-bits) and row(5-bits)).

I've added logging of the character sets (charset A&B) as a two-row monochrome font (256x64 image, each character set being 256x32 pixels). Both character sets look fine. So the problem is either in the retrieval of characters themselves or the attribute controller or DAC is doing something strange.

Edit: Found a bug in the retrieval of font/back pixels: It was using bit 2 instead of bit 3 of the attribute to select the character set.

Well, it's still strange: The fonts seem to be OK, but what's displayed doesn't match the font(it displays background pixels for all attributes without bit 3 set) for some reason?

I notice that the characters generate 0x00, 0x08, 0x10 and 0x18 as DAC input values for display, with the 0x00 and 0x08 not being visible on the black screen. The 0x00 should be correct(this is the black color), but the 0x08 seems to give the same black color as well, for some reason. So the attributes and attribute controller is actually working like they should in monochrome mode, but the DAC is generating black for both (thus the characters both being invisible with attributes 0(correct) and 1-7(incorrect)).

Time to take a look at the DAC itself.

Edit: The DAC is fine and so is the attribute controller and output generation itself. This has been tested by implementing a simple flip-flop instead of the normal character generator (getcharxy) to view output.

Edit: The output of the text generator seems fine. Currently testing text generator&attribute to DAC conversion.

I've managed to get most of the attributes working. The only strange thing still happening is that attributes 0x10-0x7F and 0x90-0xFF seem to use a grey(attribute 1-7 and/or 9-15, although since they aren't white(9-15) I can assume it's 1-7 causing problems here).

- MDA attributes seem to be working according to the earlier documentation. Bits 0-2=1 for underline, 70, 78, F0 and F8 have reversed font/background.

I get white on black for attributes 0-15, with 8-15 being brighter white, all according to the MDA documentation. The same applies to attributes 0x80-0x9F. All other characters are 'invisible', as their background is gray(the 0x8 DAC index caused by background attributes 1-7).

Is this background behaviour correct? Anyone with a MDA can confirm this?

I've managed to fix the monochrome bugs, according to CheckIt Diagnostics:
- Monochrome emulation is now based on the Misc Output Register bit 0(mono vs color emulation) instead of the Attribute Mode Control bit 2(Monochrome Emulation).
- Underline is applied to the font during text mode, when the scanline(0-13 in the case of the MDA 9x14 font) matches the number in the underline register(Not +1).
- Underline is applied when the attribute bits 0-2 is set to 001(Dosbox and FreeVGA say bits 0-2 and 4-7 being 001 and 000, but this isn't true according to the MDA page earlier in this thread, as it's table shows underline past the 16th attribute(0F) still uses underline till the end, every 8 attributes apart on index 0x11, 0x19, 0x21, 0x29 etc.).
- Monochrome mode now always disables bit 8 when creating the index for the attribute's 16-color palette(Always 7 background colors, not bright when blinking is disabled).
- Monochrome in both graphics and text modes forces the font(Always 1 instead of plane 2 font lookup table data in graphics modes) to background with attributes 0, 8, 0x80 and 0x88.
- Font reversal(foreground/background swap on attributes 0x70, 0x78, 0xF0 and 0xF8) removed, as this seems to be handled in the attribute already (attributes 7(back), F(bsck), 0(font) and 8(font), blinking between those fonts(pixel being font) and background(font masked off by blink) or always background(pixel being background/off)).

It looks like the text modes(0-3 and 7) and monochrome graphics mode(0xF) fully work on the VGA when using "mode mono". All other graphics modes either miss output or produce corrupted output(like strange data is superimposed on the image, looking like random noise).
Color mode(no calling "mode mono") seems to work correctly for all modes but modes 7(wrong(half a screen split in two character lines per character row, screen is about 320x450(half horizontal, full vertical resolution) according to the horizontal registers) resolution and attribute registers) and mode 0xF(EGA Hi-res Monochrome mode, producing black display). I know that input is correct, but CRT and Attribute/DAC is messing up colors and half resolution with mode 7(black(DAC00), dark blue(DAC 08), black(DAC10) and cyan-green kind of color(DAC18) according to the attribute controller registers and DAC colors set).

Anyone knows the cause of these problems? Does "mode mono" mess up color graphics modes too on a real VGA (tested with CheckIt Diagnostics)?

Also, what about the underline attribute? Is it used with color text modes too(With color mode in mode 7, so without "mode mono" or with "mode CO80" executed)?

Anyone?

I've managed to fix most display modes:
- All modes except mode 7 and F now work without mode mono (mode 7 messes up horizontal resolution and DAC colors, mode F gives a black screen altogether).
- Mode 0, 1, 2, 3, 7 and F now work with mode mono. All other modes mess up fully (resolution OK, but either no output(black) or junk data overlayed on the video output(like random data being overlayed in white)).

The monochrome attributes are applied when the Attribute Mode Control Register's Monochrome Emulation bit is set.

Booting in monochrome mode (reporting EGA switches 7(0111 for monochrome display) instead of 6(0110 for color display)) makes the BIOS, MS-DOS drivers and software, and CheckIt Diagnostics testing the Text modes give black on black characters instead of the usual white/bright white/gray(or any other gray scale in the case of modes 0 and 2) on black.

Anyone can see what's going wrong here or knows anything about this?

The BIOS, when booting with EGA switches bit 0 set (XXX1) writes to memory addresses A0000-A8000 instead of the set display memory aperture (Misc Graphics Register) of B0000-BFFFF. Anyone knows anything about this? Is this an error in the BIOS?

I've disabled the VGA Monochrome EGA switches (becoming 0111) and let it report 0110 for now.
Also fixed BIOS menu saying the correct names (White/Green/Amber).
Reverted monochrome background filter to be blink dependent (8 or 16 colors depending on blink setting).
Optimized b/w with more lookup tables for each b/w mode(White/Green/Amber), so 32-bit entries(with 16-bit RGB sum as the index) instead of the old 16-bit entries(with 16-bit RGB sum as the index).
Also rewritten the amber formula (B98000 for white instead of AA5500) with full R/G/B precision using floating point numbers for immediate calculations until the RGB value is createn (at which point R, G & B are converted to 8-bit unsigned integer values).

Edit: Just optimized the DAC processing to fetch DAC values straight from it's 256-entry lookup table, which is already processed from Color values to Monochrome(White/Green/Amber) when enabled. This should make the whole DAC conversion a bit faster, since there's no extra calls to the DAC function handlers anymore(just a lookup into the VGA DAC table containing RGB values to plot).
So the DAC is now essentially a double lookup table: The precalculations calculate the color DAC values and ask the renderer to update it's DAC rendering values. The BIOS menu(upon closing) just requests the latter(converting existing DAC colors into the b/w(when enabled) or color(when disabled) set in the BIOS menu).
The renderer itself only calculates the current DAC index and uses the latter lookup table(The table containing 256 colors to plot) to plot the current 8-bit attribute(which is generated by the attribute controller).
It's nicely running at 70FPS with 320x200x256 with games tested (although for some strange reason Zool crashes displaying it's loader(gray box with information about the mod)). I've only messed with the VGA color generator since last test as far as I can remember. The CPU should be working without problems?
Edit: It might simply because I've set the CPU to 8086/88. I'll set it to 80186 again and try again.
Edit: It works without problems on the 80186 CPU. Maybe it's the VGA driver like Windows 3.0 having problems with the VGA on a 8086/88?

Just worked a bit on CGA register compatibility (while looking at code of, and documentation on 8088 MPH). Managed to fix the kefrens bars and 3d objects(the pyramid, cube and donut rotating image). It will work, as long as you don't pause the emulator, which resets timing(since resetting timing puts all time to the current time, as time can't be kept while paused) to the point after the BIOS is closed. Thus timing starts at 0 again, removing any time left of the last instruction executed(essentially resetting the cycle counting), which breaks timing with 8088 MPH for this reason. The effect is that the kefrens bars and 3d object screen shows the old way (with the bars being displaced half a screen due to the offset being reset, and the 3d patch gets lifted for some reason.

Essentially, writing/reading the CGA Mode control register sets double scanning mode CGA flag on and sets a CGA flag(to determine if we're software emulating CGA through VGA).
When the CGA flag is set, writing to protected CRTC register 8 with value 2/0 sets/resets an interlace flag. Doing the same with CRTC register 4 value 1 sets/resets an single line flag.
When the protected flag in the VGA vertical retrace end register is zero(no protection), all CGA flags are reset(thus the VGA returns to normal VGA mode).

When the double scanning CGA flag is on, the scan doubling on the renderer is enabled (it's OR'ed with the Maximum Scanline register's Scan Doubling bit in the precalculations. This makes the screen display use double height, fixing the pyramid, cube and donut rotating image display to use the full VGA screen height.

When the CGA single line and CGA interlace flags are both set, the offset register of the VGA is essentially forced to 0 in the precalculations(this doesn't affect the value stored in the offset register). Thus this fixed the kefrens effect, showing the first two lines for each two scanlines, giving fast scrolling kefrens output on the VGA(it looks like the kefrens animating image is moving from the bottom to the top of the screen really fast, although the kefrens image itself(which is moving up) is correct. It shows like a black/white version of the screen capture of 8088 MPH's kefrens bars moving from the bottom of the screen to the top and then jumps back to the bottom to repeat. This happens a few times each second.

Also the CGA flag forces the VGA to use a 15.75MHz pixel clock instead of it's usual 25/28MHz clocks, as set in the Misc Output Register.

Anyone knows why the display of the kefrens is scrolling up instead of being stationary? Scali?

Of course this will only work if you put the VGA in it's accurate emulation mode (the Full synchronization mode, which runs fully according to the CPU clock, at 25/28/CGA clock speeds).