Bug 6106

Hi,  Ah, unfortunately I haven't an EGA board any more :)  What kind of mess do you get? Split screen, wrong font size, scrolling screen, completely unsynchronized screen?  Regards, Samuel 

Hi, it looks like I'm the last one who is using EGAs :)
On each board I get slightly different results.
All of them have correct Hsync, all are losing Vsync.
On one board i get a piece of one line repeated through all the screen (piece
means something like first 8 scan lines of 8x14 font), on another I get three or
four lines of text repeated.
Also there happens some strange single characters (colorful).
Thats all I remember now, because I'm writing from memory.
In about ten hours I'll be able to check this exactly on my  hardware.

Regards, Rafal

Hi again,

Any attempt to write something to VGA_CRTC_OVERFLOW register ends with scrolling
and/or blinking screen, especially doing:

outb_p(VGA_CRTC_OVERFLOW, vga_video_port_reg);
r7 = inb_p(vga_video_port_val);
outb_p(VGA_CRTC_OVERFLOW, vga_video_port_reg);
outb_p(r7,vga_video_port_val);
i lethal for EGA.


Another problem discovered in 2.6.15.4 kernel is that calling:
vgacon_set_cursor_size(c->vc_x, 31, 30);
gives similar results - quickly scrolling piece of text.

Regards, Rafal

Ah, yes, that makes sense: the overflow register is a bit different on EGA. But my book says that it "has no sense" on EGA. Which value can you read from it? 

Hi,

My book doesn't say it, but other parts of vgacon.c say: the attempt to read the overflow register will fail on an EGA. So I guess you're getting random values? Do you still get vertical sync issues when writing 0xff to the overflow register?

Regards,
Samuel

Setting bit 0 causes screen to blink (period 0.5s empty screen / some texts)
writing anything with bit 0 set to 0 (especially 0xfe or 0) results with top six
scanlines of 8x8 font of one line repeated throuhg all the screen.
(on 'Paradise' board).

Regards, Rafal.

Just for the record:
For 'Genoa' it does not matter what was written to bit 0, - blinks all the time,
and 'Victor' scrolls three complete lines of text instead of one incomplete :)

Of course I didn't checked all 256 possible values of VGA_CRTC_OVERFLOW, but
checking each bit separately didn't gave any positive results.

 

Regards, Rafal.

> Another problem discovered in 2.6.15.4 kernel is that calling:
> vgacon_set_cursor_size(c->vc_x, 31, 30);
> gives similar results - quickly scrolling piece of text.

This method of hiding the cursor does not work in EGA (docs say it produces a
split cursor, looks worse in your case).  But Linus said that we can ignore EGA
these days :-)

Ok, but the content you're reading from the overflow is bogus: that register is write-only on EGA. Could you try to just write 0xff ? 

Yes, I tried, writing 0xff ( setting bit 0 ) causes screen to blink...
I think to myself that maybe VGA_CRTC_OVERFLOW must be written in sequence witch
other register(s)...
I'll proceed witch further tests in ten hours. Meanwhile I'm digging i my
fifteen year old archive for documentation ( 5.25

At last I've found the magic number for my EGAs CRTC_OVERFLOW,
it's 0x11 (bits 3 and 5-7 seems to make no difference).

Bits 5-7 should indeed be ignored by the board.  So 0x11 works? What font size are you using ? 25*16 is 400, which should set a few bits in the overflow register.  Well, anyway. The problem here is that EGA has almost only write-only registers, so that writing to the overflow register is unsafe. I'd say we really don't want to care about all overflow bits meaning (vertical sync, etc.), so I'll write a patch for not trying to tinker with vertical display end _on EGA_. The really needed purpose of my original patch was mostly to be able to change the horizontal display end, anyway (for stty cols 70 to work nicely). 

By default, these cards display 8x8 fonts, which means 200 scanlines.
I think solution you proposed is very good, fighting with that registers is
pointless.


Now 'the cursor riddle' :-)

calling :

outb_p(0x0a, vga_video_port_reg);
outb_p(1, vga_video_port_val);
outb_p(0x0b, vga_video_port_reg);
outb_p(7, vga_video_port_val);

from vgacon_doresize gives nice fat cursor,
same code called from vgacon_set_cursor_size gives fat cursor too, but also
causes kernel to hang writing to the screen repeatedly :

Call Trace:
vgacon_cursor
hide_cursor
vt_console_print
__call_console drivers
call_console drivers
release_console_sem
con_init
console_init
start_kernel

I noticed that  vgacon_set_cursor_size is called for each line written to the
screen during this process.

Created attachment 7435 [details]
disables vertical display end tinker on EGA boards

This is against 2.6.15.4 kernel.

Could you try it please?

Works great for me, thank you very much, cursor related problem remains of course.

Best regards, Rafal

> By default, these cards display 8x8 fonts, which means 200 scanlines.  Ok,
> this makes sense: display scanlines number is below 256, but total scanlines
> number is above 256, hence the needed bits in the overflow register. 

Could you try

stty cols 72

for checking that horizontal display size works on EGA?

Created attachment 7436 [details]
cursor size fix for EGA boards

This is against 2.6.15.4.

Could you try it please?

>cursor size fix for EGA boards
Sorry, it doesn't work.

>Could you try
>stty cols 72
I'll do it tomorrow, now its too late for me :)
Best regards, Rafal

> doesn't work

i.e. it is just the same as with vanilla kernel?

And actually, when you wrote:

> vgacon_set_cursor_size(c->vc_x, 31, 30);
> gives similar results - quickly scrolling piece of text.

"scrolling piece of text": wasn't this actually the Call trace which was
getting printed over and over?

>> doesn't work
>
> i.e. it is just the same as with vanilla kernel?
Yes it is.

> And actually, when you wrote:
>
>> vgacon_set_cursor_size(c->vc_x, 31, 30);
>> gives similar results - quickly scrolling piece of text.
>
> "scrolling piece of text": wasn't this actually the Call trace which was
> getting printed over and over?

Yes, it was. It's scrolling very quickly, so I wasn't able to tell what's on the
screen, until I inserted delay loop.

Ok. Isn't there anything between Call traces that could give us a clue about why such Call traces are printed? Does your kernel has spinlock debugging on? Could you try to replace in vgacon_set_cursor_size          curs = (curs & 0xc0) | from;         cure = (cure & 0xe0) | to;  with          curs = from;         cure = to;  (i.e. erasing previous content) 

>Could you try
>stty cols 72
I tried, it works very well!

> Could you try to replace in vgacon_set_cursor_size  ...
Yes, I conducted a lot of tests with different values and all I found was that
it did not matter what was written, but when (and feeling of being stupid).

I started to experiment with dip switches on my EGAs and found that setting SW5
from ON to OFF solves the 'cursor related problem' :)
Not all of my (currently four) EGAs were affected, now all are working fine, so
if no one else complains about that, this probably was my own hardware
misconfiguration.

Also I found that using these switches, EGAs default text mode can be chosen
between 8x8 font 

Do you have documentation about this switch? Which board was this?

My cursor patch still applies anyway: the bold cursor should actually be a
non-visible cursor :)
Could you try to apply my cursor patch, and run

tput civis

for checking that the cursor becomes invisible. (run tput cnorm for getting back
a visible cursor).

It was the 'Paradise' board - the best one in my opinion.

it seems that first 4 switches are standard, the rest ? I'm not so sure.

I didn't found documentation for any of my boards :(

http://www.seasip.info/AmstradXT/1640tech/section1.html#1.22 says:
sw5:
    OFF for true EGA mode.
    ON for CGA/MDA/HERC emulation modes.
    (Also called 6845 compatible modes.)

Also look at:
http://www.seasip.info/AmstradXT/pc1640dip.html

According to these descriptions, my current setting ON ON ON off off should mean
350 scanlines which is not true. :(


And:
http://www.chips.navy.mil/archives/87_may/file7.htm
:)
and:
http://pdos.csail.mit.edu/6.828/2004/readings/hardware/vgadoc/EGAREGS.TXT
It seems that first four switches can be read through 'Input Status #0 Register'

The biggest problem with the cursor on some EGAs is that it appears two
characters  to the east of its actual position - fata morgana :)... I'll play
with it tomorrow...

> Could you try to apply my cursor patch...

I tried, it works very well on all my cards under condition that 

curs = from;
cure = to;
is also  done instead of reading old values.

If not, strange things are going on. On Genoa, for example, one can see a three
character long cursor  while it should be hidden. Or cursor displaced two
columns rightward.

Maybe You could replace 0x0a and 0x0b with VGA_CRTC_CURSOR_START and
VGA_CRTC_CURSOR_END respectively for better look ?

Best regards, Rafał

Hi,  Ah, it's interesting: that means that merely reading the ega register makes your card go crazy? I'll attach another try.  "I tried, it works very well on all my cards"  I.e. the cursor disappears as appropriate?  About numbers vs macros, yes, it looks better. But there are a lot of such to correct in the file :)  Regards, Samuel 

Created attachment 7464 [details]
cursor resize fix for EGA boards

This corrects cursor resize on ega boards: the register is write-only, so don't
even try to read it (it seems to trigger some NMI or something). And on ega,
31/30 produces a flat cursor. Using 31/31 is better: except with 32 pixels high
fonts, it shouldn't show up.

Created attachment 7465 [details]
cursor resize fix for EGA boards

Sorry, previous patch was not cleaned up...

>Hi,  Ah, it's interesting: that means that merely reading the ega
>register makes your card go crazy?
Hi,	No,  We miss understood, I'm doing too many shortcuts :)
replacing :
curs = (curs & 0xc0) | from;
cure = (cure & 0xe0) | to;
with :
curs = from;
cure = to;
Is required because writing 1's to bits 4-7 of  CRTC_CURSOR_START and
CRTC_CURSOR_END makes her go crazy :)
Probably bits 5-6 of  CRTC_CURSOR_END are so important.

So if we can't read these registers, we don't need to do that :)
Attempts to read these registers makes no harm.
Thats what I mean :)


>I.e. the cursor disappears as appropriate?

Yes, it disappears and appears back as it should, wonderful !

I'll test patch in eight hours...

Ok, I understand, but then reading them is useless, since curs = from; and cure = to; erase the read values :)

So, confirm that the patch works well, and I'll submit it to akpm.

Yes, the patch is ok.

Best regards, Rafal.

Once more I performed tests on all my EGAs, and found that problems with cursor
was caused by writing undefined values to bits 5-6 of CRTC_CURSOR_START
and CRTC_CURSOR_END only,
and calling:
vgacon_set_cursor_size(c->vc_x, 31, 31);
instead of:
vgacon_set_cursor_size(c->vc_x, 31, 30);

is not required for my cards and can be removed from the patch.

In fact putting 31 for cursor_start and anything from 0 to 31 for cursor_end,
makes it clearly invisible :)