What happens on real hardware? Are the background color bits cleared (bits 3-6 of the attribute) for the CLUT lookup? Or are they taken as in video memory, cauing a colorful display (I doubt that's intended)?

Can someone run tvdiag on a real ET3000AX and show what it outputs during the 8 simultaneous fonts test?

Hi, I have one and ran VDIAG.EXE on it a few days ago. The screen capture in the first post matches what I saw at the multi-font test. It was gray text on black background.

wbahnassi wrote on 2024-10-06, 08:29:

Hi, I have one and ran VDIAG.EXE on it a few days ago. The screen capture in the first post matches what I saw at the multi-font test. It was gray text on black background.

Ok. So that confirms that the background attribute bits (bits 3-6) are indeed cleared when sent to the attribute controller.

Does blinking still work in that mode? So that's attribute bit 7 (or an extra background color, if it's disabled). Maybe I'll need to write a program for testing that, though.

No blinking in that test. All text is static.

wbahnassi wrote on 2024-10-06, 11:06:

No blinking in that test. All text is static.

In that test at least it's logical. It doesn't set the blinking bit at all for those attributes.
I made a pascal program that will display the attributes with just the blink bit set in non-blinking mode (blinking bit is thus the extra bit of attribute, which will become color #8 on the background, if it isn't masked by the attribute controller).
When the blinking is enabled (by pressing a key), it should have the effect of changing the text from foreground to background color as normal.

The program detects the character set B character set and uses that for it's rendered text.
After another keypress, it'll return the controller back to it's original settings and return to the command line.

The source code is at UniPCemu's UniPCemu/pascal directory. It's called "fontest.pas".
It won't function properly on non-ET3000 cards though (it doesn't try to even detect a Tseng chipset, just assuming it for now). So don't run it on non-ET3000 chipsets.

I'll see if I can UniPCemu to boot again with the latest commit (again booting issues due to changed PCI handling again), then compile the program, verify it inside UniPCemu itself, then I'll put the executable here in this post.

You can of course compile it yourself as well though (didn't verify it compiling yet though, due to booting issues inside UniPCemu, with turbo.exe starting crashing 😖 ).

I don't have the Pascal toolchain, but I'd be happy to try out a compiled Exe for you on the real machine if you need to cross check anything.

After fixing the compilation issue (missing semicolon on a function declaration), it compiles and runs inside UniPCemu at least.

This is the executable and results:

The results on UniPCemu (attribute byte works as normally, except bits 3-6 are masked off before being sent to the attribute controller):
First stage: attribute byte in non-blink 4-bit background state:

Second stage: attribute byte using blink, 4-bit background state, off state (displaying font as background color):

Second stage: attribute byte using blink, 4-bit background state, on state (displaying font as foreground color):

wbahnassi wrote on 2024-10-06, 13:30:

I don't have the Pascal toolchain, but I'd be happy to try out a compiled Exe for you on the real machine if you need to cross check anything.

Any luck running the Exe?

Hi, just got to running the exe. Its results match what it says on the screen. The line that says it should be blinking is indeed blinking. I've attached the photos.

I noticed that the font looks normal on my machine, whereas yours is much wider. Is this expected?

wbahnassi wrote on 2024-10-08, 23:59:

Hi, just got to running the exe. Its results match what it says on the screen. The line that says it should be blinking is indeed blinking. I've attached the photos.

I noticed that the font looks normal on my machine, whereas yours is much wider. Is this expected?

The width is mainly a difference between physical timing (aspect ratio of the monitor actually) and the way UniPCemu clocks pixels horizontally. It's dumped before resizing to 4:3 aspect ratio(e.g. 800x600).

But your screen captures confirm it's behaviour as I implemented it: Bits 3-6 are cleared and used for font lookups only, all other bits operating normally and sent to the attribute controller for normal color processing.