You are not logged in.


#1 2005-03-31 10:53:38

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Progress

Hi!
Since nothing has been written on the forum for a while,
I post this thread to keep you updated on the progress of BOS.

I had working code to switch between VGA modes without BIOS, but that development
is now dropped becasue of some problems with my very non-standard computers.. hmm
Instead I have decided to add some 16-bit code in the kernel so that I can switch
between 16- and 32-bit (and get the BIOS int's back.. wink ).

It's now working, and it only needs to be cleaned up a bit before I continue to the real
goals for version 0.04, simple memory managment and floppy code.
Wish me good luck with that (as i tend to screw everything up).. tongue

/ Christoffer

Offline

 

#2 2005-03-31 16:42:38

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: Progress

One thing you should remember to do is this:

Code:

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

and on return this:

Code:

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

Offline

 

#3 2005-03-31 18:48:46

AxelDominatoR
Member
From: Reggio Calabria, Italy
Registered: 2005-03-07
Posts: 43
PM  Website

Re: Progress

Good luck wink
So, after memory management and floppy, you can get up on the real thing, right? Hardware accelerated OpenGL and 7.1 surround sound, right? tongue

Just kidding, you're doing a great work


---
Axel DominatoR ^^^ HC

Offline

 

#4 2005-04-05 15:47:25

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: Progress

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?


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#5 2005-04-06 08:11:11

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

Remap? But INT 10h is 16-bit. I would like to hear how that could be possible, if
you have/find any links with info I would like to have a look.

/ Christoffer

Offline

 

#6 2005-04-06 11:18:41

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: Progress

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.


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#7 2005-04-06 13:24:02

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

Ok, don't think that I will need to do it now when i already set everything up for going in and
out of pmode whenever i feel like it, but it would be fun to know what the book say anyway.. wink

/ Christoffer

Offline

 

#8 2005-04-06 19:05:54

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: Progress

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)


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#9 2005-04-07 18:59:26

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

Everything sound right except that the interrupt code use 16-bit addresses, which mean that all BIOS
interrupts that use something that depends on realmode addressing would triple
fault the PC.
Feel free to play around with my code.. wink

Yesterday I got my do_realmode_int function working! big_smile
It works for all BIOS interrupts and it takes/leaves the values in AX,BX,CX and DX correctly.
I can't remember how many int's that need other registers, but it should be enought right
now.
As the AX is already filled with function no. to my BOS int the realmode AX value must
be located in the high part of EAX and the int-number to call should be in the high part of EBX.
Did some fun stuff with opcodes and self modyfing code to get that working.. wink

/ Christoffer

Offline

 

#10 2005-04-07 22:45:27

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: Progress

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! big_smile


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#11 2005-04-08 06:25:09

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

Thanks.

I may run some tracing of INT 10h when I have an opportunity to see where it branches

Would be intresting but remember that the code for INT 0x10 will most problably not be the same on
another PC.
I even have the asm source for a small/old BIOS if you are intrested.. wink

/ Christoffer

Offline

 

#12 2005-04-08 11:33:45

DennisCGc
Member
From: Zoetermeer, The Netherlands
Registered: 2005-03-01
Posts: 49
PM  Website

Re: Progress

bubach wrote:

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

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

Offline

 

#13 2005-04-08 12:11:18

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

Yeah, but I didn't know that it was from osdever.net, can't seem to find now either.

Offline

 

#14 2005-04-11 11:29:36

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: Progress

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.


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#15 2005-04-25 09:42:23

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

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 mega-tokyo about it so...

Offline

 

#16 2005-04-25 11:38:11

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: Progress

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.


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#17 2005-04-26 06:43:35

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: Progress

Hehe.. The stack problem...
I had it a "couple" of times now...  It's fun doing ret's with bogus on the stack.. roll

About the drivers.. It sure is a chicken&egg thing. I say don't worry too much about it, make a
nice driver interface and then make the bootloader load the important ones. It would require
a recompile every time you need to add/delete a driver from the list thats going to be loaded,
but who cares? tongue

/ Christoffer

Offline

 

 

Board footer

Powered by PunBB
BOS homepage © Copyright 2005 Christoffer Bubach
Strict XHTML and valid CSS.