Im quiet newt in kernels and bootloaders.I recently wrote a basic bootloader and a kernel that should change colors in the VGA palette.The kernel doesnt make any problems runs perfectly but It does not change the colors as expectet.Since I was not able to find a mistake I tried to run the bootloader+kernel from a bootstick on my machine. I got a blackscreen and a blinking cursor.So I decided to use a gui tool for writing the bootstick ("usb-creator-gtk"), I used it to write my img file to the stick and then tested it using qemu as the program asked me to do.The bootloader was not able to load the kernel. (qemu-system-x86_64 -hda /dev/sdc)But if I use qemu-system-x86_64 -fda /dev/sdc the kernel gets loaded and works (except the VGA palette).

Post subject: Re: qemu differences between -fda and -hda(and a smal VGA is

Posted: Sun Jan 06, 2019 12:46 pm

Member

Joined: Fri Aug 26, 2016 1:41 pmPosts: 515

Regarding the issue of booting from a USB stick (and not the palette). I assume you it gave you a blank screen and cursor on real hardware? If so, were you booting your USB using FDD (Floppy Disk Emulation). This is likely a setting in the BIOS. If it is FDD then the reason it may not have worked is because of not having a BIOS Parameter Block(BPB). You might want to see my Stackoverflow Answer to see if this might have been part of the problem. If you didn't properly initialize your segments to what you need (rather on relying on values set by the BIOS before transferring to your bootloader) that could cause problems as well.

Unfortunately it is hard to tell because you only show snippets of code, and not everything.

Post subject: Re: qemu differences between -fda and -hda(and a smal VGA is

Posted: Sun Jan 06, 2019 1:11 pm

Joined: Sun Jan 06, 2019 9:20 amPosts: 4

I found out what was wrong with my code. I used x00 as bootdrive which apears to only work for floppys (-fda), I changed to 0x80 for harddrives (-hda) and the bootstick booted perfectly (on real hardware too).The only thing that remains is the palette which Im currently working on.

Last edited by FATTOMCAT on Sun Jan 06, 2019 2:17 pm, edited 1 time in total.

Post subject: Re: qemu differences between -fda and -hda(and a smal VGA is

Posted: Sun Jan 06, 2019 2:14 pm

Member

Joined: Fri Aug 26, 2016 1:41 pmPosts: 515

You don't need to hard code the boot drive. When the BIOS transfers control to your bootloader it will set DL to the drive that was booted on. If you just use the value passed by the BIOS in DL then you can avoid hard coding a value like 0x00, 0x80, 0x81 etc.

Post subject: Re: qemu differences between -fda and -hda(and a smal VGA is

Posted: Sun Jan 06, 2019 6:07 pm

Member

Joined: Tue Mar 06, 2007 11:17 amPosts: 1224

Try to remove this line. This is the PEL Mask Register. It's supposed to be already initialized by the BIOS. You need to study carefully the video mode you intend to use (whether has planes or not, memory organization, start video address, whether it uses a pallete):

Code:

write_port((unsigned char)0x3C6, 0b11111111); //init DAC mask

If it doesn't work, try to produce functions identical to the ones from Denthor's TUT2.TXT in addition to yours. Run it at least under DOSBox, extract the functions and try them. If not, something else happens with your video mode. They should work. The link I posted seems to have them in C, assembly and Pascal.

Tries to generate a random palette to demonstratechanging random colors from it.

---------------------------------------------

*/

/*Implementation

Write a byte value to port 0x3C8to set the 256-color palette indexthat we want to write.

Then write port 0x3C9 3 consecutivetimes with 1 byte to set the RGB values.

Each palette value only uses 6 effective bits(values 0 to 63). The combination of RGBfor the VGA results in a 18-bit color thatadjusts the screen from darkness to fullwhite for each color in the 256-color palette.

Pass an 8-bit index value in a byteargument to specify which CMOS memoryposition we want to read.

Write the byte index value to port 0x70.

Read the byte value at that index addressfrom the CMOS from port 0x71.

Return the contents of the CMOS byteat that position as an unsigned char.

*/unsigned char CMOS_read(unsigned char idx){ unsigned char toRet=0;

outportb(0x70,idx); toRet=inportb(0x71);

return toRet;}

/*Implementation

Work only with unsigned integers sincewe want to have at least a range of 0 to 65535even with 16-bit compilers.

Create a random value from the valuesthat change constantly in the CMOSby constantly adding the values forRTC seconds,RTC minutes,RTC hours,RTC day of week,RTC data day,RTC date month,RTC date year(CMOS positions 0, 2, 4, 6, 7, 8, 9).Read those values through a random-generatingfunction and add them all, and also addthem directly, also adding theprevious value in the CMOS "random" valuewith += for the full expression.

Also generate a random pixel startunsigned integer by adding the value ofa random-generating function and the CMOSrandom value.

The while 0 loop index must start randomlybetween 0 and 127 for added randomness.

Now, inside a loop (while 0), we willgenerate the RGB triplet values as randomlyas possible, and then we will modify eachpalette index from a random start to 255.

The R, G and B components will use the exactsame CMOS_rand expression, but we will duplicateit so that each component, each time, can beas random as possible, specially because therandom functions from Turbo C (at least 1.01)aren't truly random. They seem to produce the samerandom value always once the program is compiled,so we must use the dynamic values from the CMOSand long delaying for more randomness based on theReal Time Clock (RTC).

For each component, RGB[0], RGB[1] and RGB[2],think up on any expressions that result in highlyrandom values. After setting each of them, calldelay() or equivalent with a value between 10 and30 milliseconds for making the CMOS randomnesshave more effect.

Now write the color by calling our function tomodify the effective color of a single color indexof the 256-color VGA palette. For calling it,employ the same randomizing expression for CMOS_rand,duplicating it again, and limiting it to 0-255 byANDing with 0xFF to write random palette positionsinstead of modifying it sequentially.

Increase the while 0 index, which goes froma random start to 255. Here ends the while 0 loop.

Who is online

Users browsing this forum: Bing [Bot] and 12 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum