Just managed to get my test program to render 1 line of all 4 attributes (to planes 0 and 3 as a 2-bit spread value) by utilizing the map mask register and writing VRAM directly at segment A000 after setting the mode and precalculating one scanline of data to use for all scanlines pixels (due to floating point calculations, use precalcs for that (simply divide by 640 and multiply that by 4 once for all scanlines and rendering)).

Edit: I clearly see it rendering the pixels like it should! 4 colors in full glory mode 0Fh! Although blinking seems to be disabled? But that's the mode control register's issue of not having enabled blinking by default?

Edit: Added theortical blinking enable by adding INT 10h function 10h BX=01h. It should enable blinking (in text modes at least). But for some reason it's not activating said bit at all?
Guess I'll have to modify it manually. Luckily that's not too difficult.
Edit: Perhaps it's not required though? It looks like the INT 10h video handler already sets said bit properly.

And it looks like the blinking is an attribute controller graphics-only issue. That issue applies to all graphics mode with blinking enabled 😖

It was detecting graphics mode like blinking in this case. So all EGA additions I added were handled like in text mode (based on bit 7, which is never set in the graphics attributes!).
Besides of course handling background incorrect as well when blinking is disabled, but that won't affect graphics because they're always font pixels, never background pixels.

Yay! Fixing that seems to have fixed blinking in graphics modes! 😁

At least the blinking attribute generated by C2=1 and C0=0 is working properly it seems? I see it blinking on and off 😁

Perhaps also try what happens when I turn blinking off...
Edit: It just results in the normal attribute, which is the same as both bits set (according to the EGA palette registers)?

Btw, CheckIt reports the switches as "0010".
The adapter as 'EGA'. But the address it says "A000"?
It also doesn't use extended attributes in graphics modes (bitplane 2) at least?

Perhaps trying Simcity would use it?

Can you post your test utility? I can see if it blinks on hardware, if you haven't tested that.

GloriousCow wrote on 2024-02-10, 23:44:

Can you post your test utility? I can see if it blinks on hardware, if you haven't tested that.

https://bitbucket.org/superfury/unipcemu/src/ … niPCemu/pascal/

You'll need UNIPCEMU.PAS and MODE0F.PAS.
UniPCemu contains support logic for driving UniPCemu's own interface (like enabling logging etc., also used in my biosromexec module for running COM files from ROM as a simple BIOS for it's logging and emulator terminating support). But if it detects real hardware (in other words, the UniPCemu debugger module isn't detected), it will disable itself. It essentially uses ports E9 (for basic detection, which must return E9) and EA for interfacing (disabled if E9 doesn't implement the Bochs port E9 hack). EA (during initialization) supplies an ID to use with the Bochs debugger (written as a text line to the port E9 hack to enable the module interface on port EAh). Real hardware would float the bus reading it (as well as E9), so it won't be detected and disable functionality.

MODE0F.PAS is the actual test program. Simply compile it with a version of pascal compatible with Turbo Pascal 6.0 (as well as UNIPCEMU.PAS, before that).
Line 26 (right now)'s value 01h (or 00h) enabled or disables the blinking support in the hardware using a normal BIOS interrupt call (INT 10h).

Of course don't try to run it on non-EGA(-compatible) hardware, as there's no hardware detection or fault detection for mode switches (INT 10h calls aren't checked) and it will happily continue and write to VRAM directly (as well as VGA registers for the upper memory plane 2).

You can find the files in UniPCemu's repository, under UniPCemu/pascal. I've used Turbo Pascal 6.0 to compile it, but later MS-DOS versions should also work I think (perhaps earlier as well, depending on syntax implementations).
Perhaps free pascal etc. would work as well though.

I myself coded and compiled it entirely inside UniPCemu running the Turbo Pascal 6.0 IDE 🤣 (Based on HIGHRES.PAS (although same with all pascal code, coded within UniPCemu as far as I can remember), which does the same for mode 2Eh on Tseng cards).

Oh, interesting thing I notice just now.

Once the BIOS POSTs and the mode 7h is entered, after the XT-IDE BIOS starts booting, the cursor seems to update positions where it's blinking, although no text is put in the display buffer?

Ofc during the POST itself the cursor is disabled (using the needs-to-be lower to render trick, setting the start scanline past the end value). But apparently at least the cursor is already updated at least during the first proper mode set, although VRAM isn't addressed properly after starting to boot (or MS-DOS itself) until mode mono is executed.

Edit: Hmmm... Odd, now that doesn't happen anymore? Perhaps a weird timing (F5 press) fluke?

I'm just wondering btw...
Can't real EGA hardware help in deternining the behaviour of the 'mono' bit?

Simply set the mode to 0F, attribute registers:
- color plane enable to 0Fh OR'ed with validating bits (also during first scanline
- VRAM of first scanline to desired input (all of them, entire line/color) during half screen position (count retraces for that) Probably try to use acceleration graphics registers for that.
- Attribute registers palette 0-0F to 0-0F
- Wait for the first scanline to start, then use input status 1 with color plane enable to readout result and save it (16 entries are the literal 'mono bit' behaviour.
- Wait for it to start rendering said scanline (after vertical retrace?) after setting up VRAM
- Store the results in a buffer and dump in text mode in hex when finished.

superfury wrote on 2024-02-11, 00:20:

GloriousCow wrote on 2024-02-10, 23:44:

Can you post your test utility? I can see if it blinks on hardware, if you haven't tested that.

https://bitbucket.org/superfury/unipcemu/src/ … niPCemu/pascal/
You'll need UNIPCEMU.PAS and MODE0F.PAS.

I was hoping you could attach the binary 😁

GloriousCow wrote on 2024-02-11, 20:31:

superfury wrote on 2024-02-11, 00:20:

GloriousCow wrote on 2024-02-10, 23:44:

Can you post your test utility? I can see if it blinks on hardware, if you haven't tested that.

https://bitbucket.org/superfury/unipcemu/src/ … niPCemu/pascal/
You'll need UNIPCEMU.PAS and MODE0F.PAS.

I was hoping you could attach the binary 😁

Sure.

I've made the blinking configurable as well and the sources updated online.
Simply give it the parameter "blink" without quotes to enable blinking.
After it's done rendering, press any key to quit.

I've ran my TESTMDA utility to dump all text mode colors on the screen on an EGA (with a color monitor to clearly see the output pins of the EGA attribute controller):

In the image colors, blue=video(attribute results 08h), green=intensity(attribute results 10h), cyan=both(attribute results 18h or 3fh(entry #15)).

I tried using the custom logic I added for the weird attribute results (like every 8 out of 15 cases (attibute modudo 15=8 in this case)

The custom logic is as follows right now:

1								if (unlikely(charinnery == underlinelocation)) //Underline (Non-graphics monochrome mode only)? Ignore textmode?
2								{
3									if (unlikely((Attribute & 7) == 1)) //Underline used for this character? Bits 6-4=0(not according to seasip.info/VintagePC/mda.html, so ignore that fact!) and 2-0=1 only according to freeVGA!
4									{
5										fontstatus = 1; //Force font color for underline WHEN FONT ON (either <blink enabled and blink ON> or <blink disabled>)!
6									}
7								}
8								if (unlikely((Attribute & 0x77) == 0)) //Are we always displayed as background (values 0, 8, 0x80 and 0x88)?
9								{
10									fontstatus = 0; //Force background!
11								}
12								if ((Attribute & 0xF0) && ((Attribute & 0x77) != 0x70)) //Background set and not inversed?
13								{
14									effectiveattr &= 0xF; //Mask off any background bits!
15								}
16								if (VGA->enable_SVGA != 3) //Not on EGA?
17								{
18									//The EGA BIOS doesn't like this behaviour?
19									if (((Attribute & 0x77) != 0x70)) //Not inversed?
20									{
21										effectivebackgroundfilter &= 7; //Never include the blink bit!
22										if ((Attribute & 0x7) == 0) //Font black?
23										{
24											effectiveattr |= 1; //Use font color 1 for example?
25										}
26										else if ((Attribute & 0xF) == 0xF) //Font max?
27										{
28											effectiveattr &= ~1; //Use font color E for example?
29										}
30									}
31								}

The enable_SVGA line is also applied on the MDA, but causes the block of code to execute in that case.
effectivebackgroundfilter is used in some cases to disable the blink bit. Perhaps it doesn't like that?
Also, cases font bits being set to 0 and 15 causes weird results? Case 0 gets a black font? Is that supposed to happen?
And case 15(reg 0Fh) doesn't set full intensity? Compared to the tables at https://www.seasip.info/VintagePC/mda.html ?
Edit: Hmmm... It just needs to be able to map attribute 0F with character DBh to map to pallette register 0Fh always somehow?
It's a full block character, so all pixels are always foreground. So foreground attribute 0Fh should always map to pallette register 0Fh in said test? But doesn't the MONO bit change that when in monochrome attribute mode?
It looks like the 'Font max' line is killing the EGA BIOS POST and causing it to fail the test? But only in monochrome mode of course (color mode doesn't use said modifications).

But the attribute 15 register is causing a weird attribute to pop up for every character with bits 0-3 in the attribute set?

Edit: The testMDA utility for EGA and MDA text modes in monochrome.

Although for blinking on and off it performs a blind INT 10h and 3B8 port write for simple compatibility. That happens during the mode 7 mode set.

Like the other program, blink parameter enables blinking.

Btw, changing UniPCemu to not apply the register 0F to 0E foreground color patch and changing the 0Fh entry to be proper 18h on MDA fixes both EGA POST and those x8h attributes to match.

And the latest commit with the fixes to the attributes:

Although I'm not sure about the colors of those inverted characters?
Remember: black=both signals off, blue=video only(bit 3 of palette set), green=intensity only(bit 4 of palette set), cyan=both intensity and video signals(bits 3 and 4 of palette set).

Maybe a real EGA would be able to give the same kind of output (setting the switches to SW1=off SW2=off SW3=on SW4=off and using a color monitor instead of a monochrome monitor?
That's assuming the EGA monitor can handle the monochrome timing? Or is it unable to use that MDA signal like UniPCemu can? Mainly due to refresh rates etc.

Edit: Just tried running the EGA in color mode (dipswitches off on on off) and it seemed to use the same MDA mono bit to archieve the mode?
I see the program giving roughly the same results? Blue becomes dark blue, cyan stays the same and attribute 70/F0 become a deep red font instead, as does the entire background.
No clue about timings though.

Just modified the mode 0F source code to draw 8 pixels in one go using the EGA/VGA write mode 3. It doesn't load the latches, because it's overwriting all bits anyways (increasing throughput). It simply precalculates the 160 scanline plane colors, then writes them from there directly onto the video memory (one scanline at a time). Ofc setting up the registers before starting to draw. It doesn't set them back, as the mode set to mode 7 should do that anyways?
The map mask is simply kept to FFh to write all 8 pixels at the same time (since the colors never change in less than 8 pixels, unless you go below 128 pixels active display screen width, which isn't the case with the official video modes, speeding it up even more.

It's based on https://www.phatcode.net/res/224/files/html/ch27/27-02.html
Adjusted for mode 0Fh and 8-pixel drawing to speed it up even more (not setting the bit mask for each pixel and jumping in 8 pixel increments).

Edit: And the new executable

superfury wrote on 2024-02-14, 11:43:

Just modified the mode 0F source code to draw 8 pixels in one go using the EGA/VGA write mode 3.

Stop right there. There is no "EGA/VGA write mode 3". Write mode 3 is VGA only. Trying to use write mode 3 will cause unexpected results on actual EGA hardware.

mkarcher wrote on 2024-02-14, 19:51:

superfury wrote on 2024-02-14, 11:43:

Just modified the mode 0F source code to draw 8 pixels in one go using the EGA/VGA write mode 3.

Stop right there. There is no "EGA/VGA write mode 3". Write mode 3 is VGA only. Trying to use write mode 3 will cause unexpected results on actual EGA hardware.

Whoops. Typo in the post. I meant write mode 2 (like in the samples).

Good point though... Has anyone discovered what happens in said case it's set to 3 (actual behaviour)? UniPCemu handles it like a VGA right now. Would be nice to know for accurate emulation.
To be exact, it writes 12h to said graphics register (since manual says it's 10h on setup). So write mode 2, host odd/even memory read addressing.

I've improved the MODE0F program a bit.

Now it also supports mode 0Eh by specifying the 'color' parameter for color monitors.
It affects the color pattern rendered as well (color monitors and monochrome monitors giving all 16 attributes without 'mono' specified) and affecting the base color planes enabled (mono with color gives all planes and mono without color uses ). 'mono' also sets the MONO bit on color monitors for visual confirmation.

Basically:
- mono enables the mono bit. If not specified on monochrome monitors it will display 16 attributes with color plane enable bits all set.
- color selects mode 0Eh and 16 color pattern (or black,cyan,bright red,white for the special pattern) for color monitors. Not specifying it will select mode 0F and the old 4 color or full 16 color pattern (depending on mono being specified or not).
- blink still works as earlier (enabling blink if to be used).

Now I'm getting the following results on a color monitor emulation:
Mono bit disabled with blink enabled:

Mono bit enabled with blink disabled:

Mono
Mono bit enabled with blink disabled:

All those modes use full 16-color rendering.

What is happening on real hardware (use a color monitor and don't forget the color parameter that's mentioned to use the proper MODE 0Eh)?

The used executable will follow on the next post.

And the executable used:

Anyone willing to try this on real hardware to verify the MONO bit (the exact command line is mentioned in the previous post with the screen captures) and post some screen captures of the resulting states on the hardware?
That should tell how the EGA (or VGA too for full validation and knowledge how it performs too) performs it's blinking and MONO bit effects.
Use on a EGA color monitor of course (with enhanced graphics mode, by setting the switches to SW1=off SW2=on SW3=on SW4=off).
Although using it without the 'color' parameter on a MDA screen might also tell part of the story (switches to SW1=off SW2=off SW3=on SW4=off of course).

One nice thing with running it on a real EGA with color monitor is that is also displays the exact mapping used by the attribute controller with the MONO bit set (from the 16 color inputs on the screen). Then we finally have some real confirmation about how the attribute controller maps it's attributes with said bit set.
And the blink attribute in 16-color graphics modes is also validated as a slight bonus.

Edit: Btw, want to get real trippy? Try enabling the scanline effects with blinking in color mode (!!! epilepsy warning perhaps!!!) ;p
Simply add the waveeffect or trianglewaveeffect parameter, optionally combined with noanimation for the base non-moving version (disables the vertical and horizontal moving of the effect).