What does your OS look like? (Screen Shots..)

[BenLunt]

I was thinking the same thing.
Bring back to Screen Shots...

Here is a DOS like terminal from my OS.


Enjoy your weekend,
Ben
http://www.fysnet.net/fysos.htm
http://www.fysnet.net/osdesign_book_series.htm

[alexfru]

I was thinking the same thing.
Bring back to Screen Shots...

Here is a DOS like terminal from my OS.

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.

[Ycep]

Nice one, BenLunt!

[NunoLava1998]

gg, 10/10.

[BenLunt]

I was thinking the same thing.
Bring back to Screen Shots...

Here is a DOS like terminal from my OS.

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.

Hi Alex,

What version of VirtualBox are you using. 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 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.

Anyway, I would really like to know why your attempt didn't work. Is it an older emulator version, my code, what? Please let me know a little more information and I will see what I can do to find out why.

Thanks,
Ben

*http://www.fysnet.net/zips/fysos_efi.zip

[BenLunt]

Thanks for the comments guys. It is always interesting to see screen shots here and I look forward to seeing them. I just thought I would repay the favor and get this thread back on track again

Ben

[Octocontrabass]

My loader uses a "big" segment for the stack, meaning that all stack space is above the 1meg mark.

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.

[Sik]

Yeah, by general rule, if something doesn't work in a specific emulator/VM, chances are there's some hardware implementation out there that breaks the same way as well (simply because there's so much stuff out there that it's likely somebody else did the same by coincidence). Saying "works on real hardware" makes sense when the amount of variants is limited, but on something like PC there are so many combinations that there's never a guarantee of things working on every real system.

[NunoLava1998]

My loader uses a "big" segment for the stack, meaning that all stack space is above the 1meg mark.

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.

hardware from like 1989, that is.

[alexfru]

I was thinking the same thing.
Bring back to Screen Shots...

Here is a DOS like terminal from my OS.

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.

Hi Alex,

What version of VirtualBox are you using.

¿Was that a question? Just updated from something old to 5.0.28 r111378.

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 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.

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.

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]

What version of VirtualBox are you using.

¿Was that a question? Just updated from something old to 5.0.28 r111378.

Sorry, I sometimes forget the '?'.

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.

I am using version 5.0.26 r108824
System:
Motherboard:
Base Mem: 256Meg
Boot Order: Optical (checked), Hard Drive (checked), Floppy (unchecked), Network (unchecked)
Chipset: PXII3 (Though it works with ICH9 as well)
Pointing Device: PS/2 Mouse
Extended Features: (neither of the three are checked, unless I want EFI, then of course I check "Enable EFI")
Processor:
One Processor with a 100% Execution Cap
Enable PAE/NX is not checked
Display:
Screen:
7 Meg Ram
1 monitor
100% scale factor
Enable 3D acc is not checked
Remote Display and Video Capture are not enabled.
Storage:
floppy controller: I82078
IDE controller:PIIX3
Host I/O Cache is checked
The hard drive is not a solid state drive
Audio, Network, Serial, and USB are all disabled

Please make sure you are using the floppy or hard drive image from http://www.fysnet.net/zips/fysos_efi.zip. If you are using an older one, it will not work.

Are you using EFI enabled? If you are, and are using an older version, the kernel is still loading and working as expected, you just can't see it since it is still trying to write to screen mode 3 via 0xB8000. EFI no longer supports that screen mode. The new kernel now has everything in terminal(s), writing to a vesa compatible graphic screen.

I do not use any of the command line settings. i.e.: I do not use the command line apps that change the settings of the VM. Therefore, I am unaware of how to disable hardware virtualization as you state. I guess I could go read up on it a bit, but this just tells you that I have not messed with it, nor have I changed that setting. I only use the available settings by clicking on the settings button...

[Sik]

Stopped being lazy for a moment and got checkboxes and radio buttons working. They even pass the event down to the program, albeit at the moment it does nothing with them =P But at least widgets now are functional, at least to a basic extent.



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).

[BenLunt]

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).

Just for a thought.

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:

Code: Select all

  struct RADIO_CHECK {
    int flags;
    int value;
    struct RADIO_CHECK *next;
    struct RADIO_CHECK *prev;
  };

If the flag is set for check box, the two pointer fields are ignored. The object is either TRUE or FALSE.

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

[MichaelFarthing]

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).

Just for a thought.

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:

Code: Select all

  struct RADIO_CHECK {
    int flags;
    int value;
    struct RADIO_CHECK *next;
    struct RADIO_CHECK *prev;
  };

If the flag is set for check box, the two pointer fields are ignored. The object is either TRUE or FALSE.

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

Well personally speaking I regard this as at most a service offered to userland rather than an OS concern!
However, I think Ben prescribes things a bit too rigidly

Consider these radio buttons

Square
Rectangle
Triangle
Circle

Ticking square shuld clear triangle and circle but leave rectangle still checked.
In my apps ticking a radio sets a value and invalidates the screen.
In the succeeding draw each radio box checks its value (which it might of might not be sharing with others) to decide whether it is checked or not.
No need for any radio box to know whether the others exist or not!

But it's all a matter of taste

[BenLunt]

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.

Alex, just wondering if you found what was wrong, or have any insight to why my setup works and yours does not.
Thanks,
Ben