HELP main selectable subjects/items/topics have poor contrast

[igully]

The use of green color of the fonts with a blue background is a very poor choice in terms of readability. It has very poor contrast, and in CRT settings (many DOS vintage systems still use these type of video displays) it will most likely produce a bleeding effect.

By replacing it with light gray or even white, it would improve the situation considerably.

[bttrx]

I agree. Green is not the best color.

What about (bright) yellow?

[mateuszviste]

I am not very good with colors so I won't comment on the color choice, but:

light gray: that would make links indistinguishable from normal text, right?

white: already used by titles, I think it is better to have different colors for every function when possible...

yellow: looks good, but what about the color of "selected/highlighted link" (ie the link that the cursor is currently on)?

I am attaching a debug version of AMB for you guys to play with: ambhack.zip

The difference with normal version is that it accepts color values for links on 2nd and 3rd argument. A color value is a 8 bit value where highest 4 bits represent the background and lowest 4 bits the foreground.

Current default for links is blue background (1) and green foreground (2), that is value 18 (0x12), while "highlighted link" is the reverse color: bg 1, fg2, ie. value 33 (0x21). So:

Default:
amb file.amb 18 33

Example for red background and black foreground would be:
amb file.amb 64 4

Let me know your conclusions.

[igully]

I agree. Green is not the best color.

What about (bright) yellow?

I believe that bttrx's suggestion is a good choice.

[boeckmann]

I agree. Green is not the best color.
What about (bright) yellow?

I believe that bttrx's suggestion is a good choice.

Yes, it's also very Turbo Pascal'ish :-)

[bttrx]

@mateuszviste

Background colors with a value >15 toogle the blinking bit, so a bright yellow is not possible for the highlighted link, until you turn blinking off.

procedure toggleBlinking;
begin
	inline (
		$8a/$1e/>blinking/  { mov bl, [blinking] }
		$80/$f3/$01/        { xor bl, 1 }
		$88/$1e/>blinking/  { mov [blinking], bl }
		$b7/$00/            { mov bh, 0 }
		$b8/$03/$10/        { mov ax, 1003h }
		$cd/$10             { int 10h }
	);
end;

Here is an example using the value of 33 you mentioned:

@boeckmann

You got me. ;-) I got my inspiration from the TP6 IDE.

[mateuszviste]

Background colors with a value >15 toogle the blinking bit, so a bright yellow is not possible for the highlighted link, until you turn blinking off.

I am aware of that, but it's a EGA-specific feature. Meaning that on CGA it will not work and hacking CGA registers would be needed (along with some detection of the actual hardware).

That being said, I am not against yellow at all, but perhaps it could be used for non-highlighted links, and the highlighted links would have some slightly different scheme that could accommodate all (color) hardware without any hacks?

EDIT: is that what you actually suggest in your latest screenshot? ie. Yellow for non-highlighted links and green bg for highlighted ones?

[bttrx]

I am aware of that, but it's a EGA-specific feature. Meaning that on CGA it will not work and hacking CGA registers would be needed (along with some detection of the actual hardware).

I knew in advance, you would mention this. ;-)

That being said, I am not against yellow at all, but perhaps it could be used for non-highlighted links, and the highlighted links would have some slightly different scheme that could accommodate all (color) hardware without any hacks?

ACK

EDIT: is that what you actually suggest in your latest screenshot? ie. Yellow for non-highlighted links and green bg for highlighted ones?

It's an example, nothing more.

I think, it doesn't look too bad, but someone might come up with a better suggestion.

I don't use the HELP command very often, coz I know everything about (Svar)DOS by heart. :-D

[mateuszviste]

Let's move on with this, guys. Four propositions below. I have tested them and they all render reasonably consistently on all hardware and all platforms (incl. things like windows shell and linux terminals).

My personal favorite is variant 0x2f, but the other are also nice, esp. variant 0x20... It's a hard choice.

variant 0x21:

variant 0x20:

variant 0x2e:

variant 0x2f:

[boeckmann]

I think 0x2f will be the easiest to read.

[mateuszviste]

I think 0x2f will be the easiest to read.

Adopted in AMB 20240131 then :-) (and integrated within SvarDOS build 20240131).

[boeckmann]

@mateuszviste nice progress the last days :-)

[mateuszviste]

@mateuszviste nice progress the last days :-)

Thanks, you're very kind, but my performance is really pathetic compared to the awesome leaps you are doing on the EDR front. I'm sadly not able to help you on this journey, but I'm very much rooting for further successes! (and waiting for a "clean/stable" EDR kernel-only package) :-D