One thing you should remember to do is this:

mask_irqs:
        cli
        mov  al,255       ; mask all irqs
        out  0xa1,al
        out  0x21,al
        ret

and on return this:

unmask_irqs:
        mov  al,0         ; unmask irq's
        out  0xa1,al
        out  0x21,al
        sti
        ret

Thats if you remapped your pic's, as if not you may find your keyboard not working proply, that what append to me.

Also if you can remap pic's to realmode setting you can easily use bios int 13h for not only floppy, but also Hdd, the other advantage to this is people with USB floppy can load stuff with out a USB driver, as long as the bios supports it.

I am thinking about adding int 13h support to "Dex4u" .

PS: Good luck  .

I have read that you can remap realmode INT 10h into protected mode without difficulties. I haven't verified this but it seems possible since 10h isn't one of the exceptions for protected mode. Has anyone worked on this?

It was in Barry Brey's book. I'll quote his wording when I get the opportunity. I'm at work now...

I realize that it is 16-bit code, though according to his wording it is possible to use it. Remapping; I mean using the IVT entry from realmode in your IDT, but as a 32-bit entry point. I suspect it isn't as simple as that though, if you remap the PIC, then you'll have to turn it back on etcetera before returning to un-interrupted (pun intended) code.

Unfortunately I haven't yet worked with an IDT so it would be beyond my grasp at the moment. However, if you have the opportunity, since you've already worked with the IDT, you could easily check it, I suspect.

From Barry Brey's Book: The Intel Microprocessor 8086/8088, 80186/80188, 80286, 80386, 80486, Pentium, Pentium Pro Processor, Pentium II, Pentium III, Pentium 4 Architecture, Programming, and Interfacing. This is from Chapter 12-1 Basic Interrupt Processing, under the heading of Operation of Protected Mode Interrupt, 3rd paragraph:

Barry B. Brey's book: wrote:

Real mode interrupt vectors can be converted into protected mode interrupts by copying the interrupt procedure addresses from the interrupt vector table and converting them to 32-bit offset addresses that stored in the interrupt descriptors. A single selector and segment descriptor can be placed in the global descriptor table that identifies the first 1M byte of memory as the interrupt segment.

Other than the IDT and interrupt descriptors, the protected mode interrupt functions like real mode interrupt. We return from both interrupts by using the IRET or IRETD instruction. The only difference is that in protected mode the microprocessor accesses the IDT instead of the interrupt vector table.

That being said (read), it seems logical to me that you could say, remap 10h to say 50h in the IDT and call it. You would naturally need enough stack for the particular happenings inside the interrupt routine, but it seems like it should work, according to these two paragraphs.

But, since I haven't gotten to IDT useage yet myself, I won't toy with it until I do to see if it indeed works. I may use your 0.03 code and see if I can read 10h's SEG:OFF and convert it to 32-bit linear and put it into say 50h and try to reset to mode 3 text color.

Last edited by smiddy (2005-04-06 19:07:11)

I think you have a good point. Most BIOS interrupts do calls based on 16-bit offsets, or far calls with 16-bit segments and offsets. I may run some tracing of INT 10h when I have an opportunity to see where it branches.

Cool, congrats on successfully going back and forth from real-to-protected-and-back-and-back!

bubach wrote:

I even have the asm source for a small/old BIOS if you are intrested..

You mean the XT Bios ? (downloadable at wwwosdever.net)

I have seen that BIOS which wouldn't help much for an AT (psuedo) style BIOS. I also agree that all BIOS' are not created equal. I have four type to look at at home: Phoenix, AMI, HP, and Award. I suppose I could compare them for differences. I am only going to look at INT 10h and not try to dissassemble the whole BIOS code. I really want to know if I can make calls to the code.

I was working on BIOS32 this weekend. I was able to do PCI32 enumeration in protected mode using Class Codes. I'm on the edge of writing my IDT and using interrupts in protected mode. I am going to enumerate the PCI IRQ Table next (proabably not until next weekend) to see how everything is setup.

Has anyone here worked with BIOS32? I'm real curious about ACPI stuff and was wondering if anyone has run into using it at all. Also, I am less curious about Plug and Play '$PnP' BIOS information.

bubach wrote:

oh, sorry but i missed your latest post totally.. :S

I haven't tried anything myself, and it seem that you already started a thread on mege-tokyo about it so...

Yep, I was able to see that the segmentation of INT 10h would hinder the process so I will leave video alone until I am ready to begin implementing it in my own code.

I was able to enumaerate the PCI IRQ table as well. Nothing really to it, other than it gives you an idea of what the motherboard is capable of doing with the installed classes of devices.

I am currently working on memory management. I am working with physical memory at the moment and as yet haven't read up on virtualizing it. I can assign and unassign memory blocks. I am using two methods for assurance. The tried and true bitmap method and a table that corresponds to assigned/free memory at a 4kB/block.

I still haven't implemented IDT or keyboard driver. I am waiting to do this because I am working on a way to implement device drivers outdie of the kernel code. My current thoughts:

1. Have a CONFIG.SYS like file that says which driver to install; if unavailable load basic drivers: keyboard, floppy, console.
2. Load them in Unreal mode since I have access to the full memory range during this time, using INT 13h via the floppy.
    -- this opens up some debate since what if I want to boot from the HD, then it will present some problems.
3. FAT 12 support for floppy loading; may be rudementary within kernel and trashed once file manager has loaded external drivers.

It is as always a work in progress.

One thing I've noticed during my coding that I frequently run into: I forget some times to pop previously pushed items from the stack. The code tends to do wacky stuff due to the misallignment of stack items. Which at times leads me down debugging roads I don't need to... The learning process, wow what a concept.