The Place to Start for Operating System Developers
http://f.osdev.org/
Looking nice. Though you should try running it in VirtualBox. It goes as far as changing the mode to 800x600 and then something happens or does not happen. The screen is black, the log is not immediately helpful.BenLunt wrote:I was thinking the same thing.
Bring back to Screen Shots...
Here is a DOS like terminal from my OS.
Hi Alex,alexfru wrote:Looking nice. Though you should try running it in VirtualBox. It goes as far as changing the mode to 800x600 and then something happens or does not happen. The screen is black, the log is not immediately helpful.BenLunt wrote:I was thinking the same thing.
Bring back to Screen Shots...
Here is a DOS like terminal from my OS.
Are you using a 32-bit stack in real mode? That will definitely fail with some hardware, even if you haven't encountered it yet.BenLunt wrote:My loader uses a "big" segment for the stack, meaning that all stack space is above the 1meg mark.
hardware from like 1989, that is.Octocontrabass wrote:Are you using a 32-bit stack in real mode? That will definitely fail with some hardware, even if you haven't encountered it yet.BenLunt wrote:My loader uses a "big" segment for the stack, meaning that all stack space is above the 1meg mark.
¿Was that a question?BenLunt wrote:Hi Alex,alexfru wrote:Looking nice. Though you should try running it in VirtualBox. It goes as far as changing the mode to 800x600 and then something happens or does not happen. The screen is black, the log is not immediately helpful.BenLunt wrote:I was thinking the same thing.
Bring back to Screen Shots...
Here is a DOS like terminal from my OS.
What version of VirtualBox are you using.
Just updated from something old to 5.0.28 r111378.I tried both. Same outcome. I can see the loader progress bar, the mode change and then nothing. If I disable hardware virtualization, however, at that point the VM throws some kind of error and I can't make much sense of the VirtualBox log. Please try the same.BenLunt wrote:I booted the given hard drive image* both with EFI enabled and Legacy Boot and it booted all the way to the command prompt shown here. Also, I booted the floppy image given, Legacy only, and it booted, though since the graphic image files were missing, it didn't show the background. [now included in the image file shown below]*
I'm playing with big real/unreal mode support in the compiler and am revisiting stack-related code. I'm planning to eradicate dependencies on the top 16 bits of ESP in the huge and unreal modes (by doing MOVZX EBP, SP in function prologues and similar things elsewhere). This should make things a bit more robust. The BIOS should not corrupt EBP in its ISRs, too dangerous. If it does that to your code at arbitrary times, you don't have much of a remedy, except, perhaps, wrapping its ISRs into something that preserves EBP or whatever GPR.BenLunt wrote:I am using Oracle VirtualBox 5.0.26 r108824, booting the fysos.bin.vhd with EFI enabled (and again without). The fysos.bin.vhd image is bootable either EFI or Legacy with no interaction from the user. Simply change VirtualBox to support EFI or Legacy BIOS.
Both the EFI and Legacy loaders are to find a 1024x768x16 screen mode by default, then a few others, including 800x600x16 if those are not found. This means that your VirtualBox did not offer the 1024x768x16 screen mode.
My loader (both EFI and Legacy) watches for a F8 keypress during boot. If it finds that the user pressed the F8 key, it will list all available screen modes and allow you to choose one before booting the kernel. Wait for the loader to start loading the files (seen by the progress bars) and then press the F8 key (once). After loading the files and just before it moves to the kernel, it will display the list of available modes, allowing you to choose one.
However, there is a caveat, unfortunately. The Legacy BIOS support in VirtualBox, when a key is pressed, must modify the high order word of the ESP and/or EBP register(s) or the SS selector. My loader uses a "big" segment for the stack, meaning that all stack space is above the 1meg mark. This can be used as long as the BIOS correctly uses the stack. For example, if the BIOS assumes it can use the callers stack, all access will still be above the 1Meg mark since the SS selector was not modified. If the BIOS creates its own stack, as long as it restores it to its original state, this is still okay. For some reason, the Legacy BIOS used in VirtualBox does not work under these conditions. This technique works in Bochs, QEMU, and real hardware, but not in Virtual Box. Therefore, pressing F8 during a Legacy BIOS boot in VirtualBox will freeze/crash the emulation. Pressing F8 during an EFI BIOS boot in VirtualBox is okay, as well as in Bochs (Legacy only), QEMU (Legacy only), and real hardware.
Sorry, I sometimes forget the '?'.alexfru wrote:¿Was that a question?BenLunt wrote:What version of VirtualBox are you using.
I am using version 5.0.26 r108824alexfru wrote:I tried both. Same outcome. I can see the loader progress bar, the mode change and then nothing. If I disable hardware virtualization, however, at that point the VM throws some kind of error and I can't make much sense of the VirtualBox log. Please try the same.
It would be good to know exactly how you create your VM in VirtualBox as there are quite a few options to play with and we don't know if it's one or more of them that "break" things.
Just for a thought.Sik wrote:Those radio buttons are there for testing >_>; They behave mostly like checkboxes so it was a quick addition so I may as well go and try it. Internally checkboxes and radio buttons are pretty much the same thing, the main thing is that a checkbox toggles its associated variable between 0 and 1, while a radio button sets the variable to its value (radio buttons belogning to the same setting will affect the same variable, probably simpler than having to create a container just to group them together).
Code: Select all
struct RADIO_CHECK {
int flags;
int value;
struct RADIO_CHECK *next;
struct RADIO_CHECK *prev;
};Well personally speaking I regard this as at most a service offered to userland rather than an OS concern!BenLunt wrote:Just for a thought.Sik wrote:Those radio buttons are there for testing >_>; They behave mostly like checkboxes so it was a quick addition so I may as well go and try it. Internally checkboxes and radio buttons are pretty much the same thing, the main thing is that a checkbox toggles its associated variable between 0 and 1, while a radio button sets the variable to its value (radio buttons belogning to the same setting will affect the same variable, probably simpler than having to create a container just to group them together).
A radio button and a checkbox can be an identical object, only a flag specifying which to draw. For example, here is part of the object:If the flag is set for check box, the two pointer fields are ignored. The object is either TRUE or FALSE.Code: Select all
struct RADIO_CHECK { int flags; int value; struct RADIO_CHECK *next; struct RADIO_CHECK *prev; };
If the flag is set for Radio, the two pointer fields are now used to group the radio buttons together. When a radio button is checked, your handler can scroll through all the other buttons in this group and make sure they are unchecked.
As with the drawing handler, the same code can be called for both types of objects, the flags field indicating to draw a circle or a box. Other flags can be used to indicate if there is text and if so, which side of the box/circle it is drawn on.
Just a thought for you to think about,
Ben
http://www.fysnet.net/osdesign_book_series.htm
Alex, just wondering if you found what was wrong, or have any insight to why my setup works and yours does not.alexfru wrote:I tried both. Same outcome. I can see the loader progress bar, the mode change and then nothing. If I disable hardware virtualization, however, at that point the VM throws some kind of error and I can't make much sense of the VirtualBox log. Please try the same.