Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
On Mon, 7 Mar 2016, Programmingkid wrote:
Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
Maybe. I've seen the same with Finnix which prints dark gray on black. But the reason could also be that on Apple (and Sun too I think) the default screen color is light so these loaders are using dark colors for text without changing background color which is black on OpenBIOS. Is it better to change the default background to a light gray color?
Regards, BALATON Zoltan
On Mar 8, 2016, at 6:35 AM, BALATON Zoltan wrote:
On Mon, 7 Mar 2016, Programmingkid wrote:
Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
Maybe. I've seen the same with Finnix which prints dark gray on black. But the reason could also be that on Apple (and Sun too I think) the default screen color is light so these loaders are using dark colors for text without changing background color which is black on OpenBIOS. Is it better to change the default background to a light gray color?
Isn't the background color in OpenBIOS yellow?
On 08/03/16 03:55, Programmingkid wrote:
Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
color! definitely does work as I spent some time digging into it when I rewrote the framebuffer code a while back. The issue seemed either endian or depth related because the problem goes away in 8-bit mode, e.g. try booting with -g 800x600x8 but I didn't really dig that far.
ATB,
Mark.
On Mar 8, 2016, at 2:42 PM, Mark Cave-Ayland wrote:
On 08/03/16 03:55, Programmingkid wrote:
Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
color! definitely does work as I spent some time digging into it when I rewrote the framebuffer code a while back. The issue seemed either endian or depth related because the problem goes away in 8-bit mode, e.g. try booting with -g 800x600x8 but I didn't really dig that far.
Why is it when I 'see' color! in OpenBIOS, the word is empty?
On 08/03/16 20:31, Programmingkid wrote:
On Mar 8, 2016, at 2:42 PM, Mark Cave-Ayland wrote:
On 08/03/16 03:55, Programmingkid wrote:
Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
color! definitely does work as I spent some time digging into it when I rewrote the framebuffer code a while back. The issue seemed either endian or depth related because the problem goes away in 8-bit mode, e.g. try booting with -g 800x600x8 but I didn't really dig that far.
Why is it when I 'see' color! in OpenBIOS, the word is empty?
Well the "see" routines in OpenBIOS aren't 100% complete IIRC. Take a look at driver/vga.fs and in particular color! which should call into the VGA palette routines.
ATB,
Mark.
On Mar 9, 2016, at 1:38 AM, Mark Cave-Ayland wrote:
On 08/03/16 20:31, Programmingkid wrote:
On Mar 8, 2016, at 2:42 PM, Mark Cave-Ayland wrote:
On 08/03/16 03:55, Programmingkid wrote:
Some Linux distributions like Fedora start booting to an all black screen. I found out the reason why is because there appears to be something wrong with the screen node's color! word.
If you type these commands in OpenBIOS: dev screen see color!
You will see that color! is empty. This would definitely prevent the color of text from being changed.
color! definitely does work as I spent some time digging into it when I rewrote the framebuffer code a while back. The issue seemed either endian or depth related because the problem goes away in 8-bit mode, e.g. try booting with -g 800x600x8 but I didn't really dig that far.
Why is it when I 'see' color! in OpenBIOS, the word is empty?
Well the "see" routines in OpenBIOS aren't 100% complete IIRC. Take a look at driver/vga.fs and in particular color! which should call into the VGA palette routines.
I just used -g 800x600x8 in QEMU and the black screen problem was gone. If this is an endian problem, what would you suggest be the solution to the problem? OpenBIOS VGA flag sent to vga.c forcing big endian mode? -VGA-big-endian command-line option?
On 09/03/16 18:03, Programmingkid wrote:
Well the "see" routines in OpenBIOS aren't 100% complete IIRC. Take a look at driver/vga.fs and in particular color! which should call into the VGA palette routines.
I just used -g 800x600x8 in QEMU and the black screen problem was gone. If this is an endian problem, what would you suggest be the solution to the problem? OpenBIOS VGA flag sent to vga.c forcing big endian mode? -VGA-big-endian command-line option?
As a starting point, try logging the writes to the VGA registers in QEMU and see how they differ between 8-bit and 32-bit colour depths. Unfortunately I'm fairly tied up with other things right now, but I will try and help out if you post questions to the list.
ATB,
Mark.