Switch To Real Mode Temporarily

Topics: Developing Cosmos (Working on Cosmos source code directly), Other, Using Cosmos (Developing your own OS, projects, etc)
Developer
Apr 22, 2014 at 5:08 PM
Edited Apr 22, 2014 at 5:11 PM
Im having a bit of a problem with " use16 ". The project doesn't compile if i use "use16" in a piece of code. Im trying to switch to Real Mode but the code doesn't work without " use16 "

Image



PS: I tricked the compiler in including " use16 " before the jump to the label " UReal "
and i already have 16 bit protected mode segements
Coordinator
Apr 23, 2014 at 6:45 AM
This is a general assembler problem. The assembler needs to run in 16 bit mode (using use16) for it to do that. But this really is not the thing intended to be done by cosmos. If you want these kinds of things, you'd be better of going for things like c or so..



2014-04-22 19:08 GMT+02:00 forest201 <[email removed]>:

From: forest201

Im having a bit of a problem with " use16 ". The project doesn't compile if i use "use16" in a piece of code. Im trying to switch to Real Mode but the code doesn't work without " use16 "

Image

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Apr 23, 2014 at 3:00 PM
:) i found another way of using the above code. If i load the code as an external process/thread it works perfectly
Coordinator
Apr 23, 2014 at 3:09 PM
You mean as a binary blob into memory and jumping there?



2014-04-23 17:00 GMT+02:00 forest201 <[email removed]>:

From: forest201

:) i found another way of using the above code. If i load the code as an external process/thread it works perfectly

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Apr 23, 2014 at 3:34 PM
Why not write the entire low level real mode code in assembler or C, link it with the kernel and relocate it? Seems much easier than using Cosmos.Assembler, man that doesn't even work with my Cosmos distribution.
Developer
Apr 24, 2014 at 12:44 PM
Edited Apr 24, 2014 at 12:53 PM
mterwoord wrote:
You mean as a binary blob into memory and jumping there?
Yes. It loads as a process in a pre-emptive scheduler.
i tried using the ' jmp ' instruction to jump to the code but it causes a GPF. So i decided to make it a process instead.

Oh it seems Vmware doesn't set VESA resolutions. The code works in VirtualBox perfectly. Does Vmware support the standard way of setting VESA via BIOS Int 10h?
Apr 27, 2014 at 2:35 PM
AFAIK switching to real mode is a large flaw in your design, the problem is worsened by the fact that under real mode the BIOS handles the IRQ interface. Say you've two processes.
Process A.
Process B.
Process A wants to switch to 640x480 resolution mode, while Process B is waiting for debugger connection from the serial port. See the problem?
Switching to Real Mode after custom hardware configuration is a complex procedure, you must restore all the original firmware configuration, remap the interrupt controller (any sane person will remap the interrupt controller after proper CPU Initialisation), disable interrupts, lose all of your handlers, and if a fault happens there, you'll have no chance.
Back to the question, when Process A will tell the kernel to switch to video mode it'll fall to real mode, imagine if suddenly the debugger dispatches the signal while the switch is happening, you'll lose it.
Another problem is CPU usage, you can't make the CPU do useful stuff while switching video modes (example: reading a disk sector etc.), why waste 100% of CPU time while just switching a video mode?
If Cosmos wants to be managed, why not write Real Mode managed code? :-). In my OS there is a program called "vmode", whenever I want to switch video modes I just execute the program with the appropriate arguments. The program is linked against RME.A (Real Mode Emulation Library) and is written in C. It copies the BIOS Code to the emulator's address space, loads the IDT inside the emulator, and executes the interrupt with the registers. Instead of RME you can use x86emu. If you want to be more hardware specific Virtual 8086 is always there to help you, but remember that virtual 8086 is legacy crap and is not at all available in x86-64 mode, so after you've got decent video you can't get nice x64 code. Using x86 Emulation will also work on other architectures like ARM, which are equipped with x86 Video cards.
Links:
x86emu - https://github.com/wfeldt/libx86emu
RME - http://git.mutabah.net/rme2.git
Coordinator
Apr 27, 2014 at 3:19 PM
We don't want BIOS interrupts, as it makes the os unstable..



2014-04-27 16:35 GMT+02:00 ALLDESP <[email removed]>:

From: ALLDESP

AFAIK switching to real mode is a large flaw in your design, the problem is worsened by the fact that under real mode the BIOS handles the IRQ interface. Say you've two processes.
Process A.
Process B.
Process A wants to switch to 640x480 resolution mode, while Process B is waiting for debugger connection from the serial port. See the problem?
Switching to Real Mode after custom hardware configuration is a complex procedure, you must restore all the original firmware configuration, remap the interrupt controller (any sane person will remap the interrupt controller after proper CPU Initialisation), disable interrupts, lose all of your handlers, and if a fault happens there, you'll have no chance.
Back to the question, when Process A will tell the kernel to switch to video mode it'll fall to real mode, imagine if suddenly the debugger dispatches the signal while the switch is happening, you'll lose it.
Another problem is CPU usage, you can't make the CPU do useful stuff while switching video modes (example: reading a disk sector etc.), why waste 100% of CPU time while just switching a video mode?
If Cosmos wants to be managed, why not write Real Mode managed code? :-). In my OS there is a program called "vmode", whenever I want to switch video modes I just execute the program with the appropriate arguments. The program is linked against RME.A (Real Mode Emulation Library) and is written in C. It copies the BIOS Code to the emulator's address space, loads the IDT inside the emulator, and executes the interrupt with the registers. Instead of RME you can use x86emu. If you want to be more hardware specific Virtual 8086 is always there to help you, but remember that virtual 8086 is legacy crap and is not at all available in x86-64 mode, so after you've got decent video you can't get nice x64 code. Using x86 Emulation will also work on other architectures like ARM, which are equipped with x86 Video cards.
Links:
x86emu - https://github.com/wfeldt/libx86emu
RME - http://git.mutabah.net/rme2.git

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Apr 29, 2014 at 3:12 PM
I know its a flaw. Its just a temporary solution for graphics. Right now im using VGA registers. I already get a resolution of 1024x768x8 using VGA registers but drawing is a problem cause it looks like the SVGA cards' MIMO points to Linear Framebuffer (Virtual PC).
Coordinator
Apr 29, 2014 at 4:31 PM
Using the bootloader, we ask for a LFB if i recall correctly.

Just using VGA ports should work in protected mode..



2014-04-29 17:12 GMT+02:00 forest201 <[email removed]>:

From: forest201

I know its a flaw. Its just a temporary solution for graphics. Right now im using VGA registers. I already get a resolution of 1024x768x8 using VGA registers but drawing is a problem cause it looks like the SVGA cards' MIMO points to Linear Framebuffer (Virtual PC).

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com