That will be great, we can try differant demos see which works best or may be using the best bits from all the differnt demos :). Talking about tools, just got my own metal workshop set up with new lathes and millers etc, i have already ear marked a mini mill for a CNC using "Dex4u" to run the g-code , i will be doing a full write up about it, also on the list is a "Dex4u" robot 8).

Update, i have been working on some, simple drivers for "Dex4u", when i first made the drivers, i made them to run in realmode, and used bios int for printing messages etc (simpler for testing ), As part of the Driver Interface, that "Team OSDevRus" which is a group of os dev getting together to design a common driver interface, i have been converting the drivers to "Dex4u" also on the way i have tyred to make them os independent, so far i have converted CdPod ( a cd player, that can be used for driver testing), and a SB16 Pro driver, i am now working on converting AC97 driver. These drivers will be able to be load and unload on the fly. Heres the basic way it works, first the drivers will have as little OS dependent code as possable as stated above, but some function will be needed like print, timer etc. The way we can use these function even though we implement them differently is to all have a call table like "Dex4u" that can be included with the driver and points to the address of the function in our os that say does the print string or timer or may be pci etc, even if like bubach you use int only, in the int function it still calls a function that does the job, this is the address the can be pointed to. As long as we use the same label name in the function include and agree on error code and how we pass info to the function we should be OK. Anyway i will keep you's informed :).

Great! Mmm... I'll post something interesting later maybe. I'm still half-sleepy and I'm not probably able to write a correct tought :P

I think a call table will be the simplest to implement. Thoughts on OS commands... PrintString (like a standard out) Add to IDT (one for IRQs and one for user INTs) Remove from IDT (same as above) TimerTic (< We need to determine a default value, mine is running at 1 kHz) PrintChar (with standard text attribute convention in AH, AL = char) Cursor (manipulation of locations, getting locations) Thoughts on driver commands: Install Uninstall And: ISR I have some thoughts put together on my keyboard driver...which seems to work already. I need to put in into a seperate file and test it.

First, I am new here and new to OS development and am learning quite a bit from you guys. Thanks for the enlightening discussion. On the subject of common driver interface, is there anything in the proposed EFI (Extensible Firmware Interface) specification that will be helpful in this context? http://www.intel.com/technology/efi/main_specification.htm#update I believe EFI will be a very important technology for us as we move forward with our OS projects, not only in terms of driver support (some interesting pre-OS capabilities and lots or room to "stuff" things we need).

Hi all, @smiddy, I agree with all your function you mentioned, i would also add a WriteHex function, for when we are test on our different OS and need to dump a reg. @HyperVista, first let me welcome you to the forum and your first post, i will take a look at the link and read about it. Also if any member has not already seen "HyperVista" web site, you should, as it looks a interesting project. http://www.hypervista-tech.com/

@Dex4u, Yeah, I forgot about those little tid-bits of code that are useful for testing. Perhaps a Debug routine or something along those lines that would dump the register data...this may be a stretch on my part. I think the other internal driver routines might be something along the lines Alex was talking about. Set up basic functions for use...which would standardize the functions for device type, say using the Class Codes from PCI? There's a page or so full of them, so it would take some time ironing out the details for each device type. As goes the course, those critical items for the OS would be done first, then follow with TV monitors, etcetera, as they aren't so critical to teh OS, unless you intend on competing for a Media Center type OS. @HyperVista, How's the weather? ;) The reason I ask is my wife is in D.C. today and she said it was raining today. Plus it seems an appropriate lead in... Thanks for the link. When I am able I'll give it a look-see. Having delt with firmware before, I might have a preconcieved notion of how it reads. But I'll give it a shot. Also, welcome to the site! This is certainly a huge learning experience for me too. I couldn't agree with you more. Enjoy!

@Dex4U - Thanks for the kind words of welcome. I hope to contribute to this community (once I get my bearings). @smiddy - Thanks, too, for the words of welcome. I'm about 15 miles NW of Washington, D.C (about 2hrs drive .... <grin>). It rained some this morning, but the sun is coming out now generating that famous WDC mugginess. - later!

Hello HyperVista, welcome! :D I gave the EFI specification a small reading. There are surely some interesting point we could discuss about and that may be useful to our driver specification... I'm a bit busy with finishing the main part of FutureSeek site, so I will not be too much active for few days... but I could setup facilities on my server for the project when the site is ready: maybe a wiki, a forum section about it, other things if needed. Or, if anyone already planned to host itself, then I could make a mirror.

Greetings Dex4U and AxelDominatoR. Are you suggesting a new forum topic on EFI? If so, I'd be more than happy to help with that. Just let me know how I can help. I suspect EFI will be fairly mainstream in 18 months to 2 years from now (Intel and other IT giants are pushing it and all the major BIOS manufactures have fallen in line). There are quite a few nice features (and some serious drawbacks too) with EFI which we can and should take advantage of as we comtemplate a common driver architecture. In addition to the driver considerations, there are lots of bootload considerations and persistence opportunities with EFI. For example, in my project, my OS is simply a hypervisor (very lightweight OS whose main applications are other OSes). There are a number of privileged executions which can not be virtualized directly, i.e. I have to perform a dynamic binary translation because it's impossible with these processes to do direct execution. Naturally, there is a performance hit with binary translation so one could build a binary translation trace cache as the system runs and subsequent privileged calls don't need to go through the binary translation, which helps with performance. One could use the space provided in EFI to serialize (persist) the binary translation cache so it's available between boots and provided a more responsive virutualization experience the more the system is used. Don't get me wrong ... I'm not a big fan of EFI. I think it's going to be a dominate factor in near future systems and like it or not, I think we'll be dealing with it at some point and better to get a handle on it now. Anyway, as AxelDominatoR pointed out, there is much in EFI that we can discuss and if you want, I can help facilitate that (a little). Let me know. - Hypervista

Hi all. @HyperVista, i think he was meaning the whole Common Driver Interface. I have bean doing a little bit of reading on "slashdot" about your projet, http://it.slashdot.org/article.pl?sid=05/06/07/2028218&tid=201&tid=218 http://developers.slashdot.org/article.pl?sid=03/10/02/1232235&tid=156&tid=8&tid=106 My own thoughts are that a bootable web browser, is what the future OS will look like, every thing else will be available off the web through the browser. Thats why i will be making a web browser for "Dex4u". I think there will be a big push for this type of technology by a very, very big software co, as a way to kill the compation, but i think "google" may prefer the bootable browser idea :wink:

Greetings All @Dex4U Thanks for the reply. Very interesting concept, bootable web browser as OS. I think you may be on to something there! Some colleagues and I were discussing not too long ago about how complex and large browsers have become and that they have become very much similar to OSes in terms of codebase size and functionality. Your idea sounds like the utlimate thin client concept. I wish you luck with that effort. Any thoughts on porting it to smart phone devices? Browsers are becoming ubiquitous! You're right about a very, very large software company pushing the hypervisor solution ... others are as well (XenSource, VMWare, etc.). M$ is dropping the ball on hypervisors, though. Although they plan on providing hypervisor support in Longhorn, theirs won't be ready until 2007!! Intel and AMD will be ready for hypervisor functionality later this year and early next year (VT, LaGrande, and Pacifica chips). I hope to fill the void left by M$ in the home user hypervisor market being created by Intel and AMD with their new chips (XenSource, VMWare are focusing on the enterprise and server farm market, I want to focus on the mom and pop home user that MS is putting off until 2007...). But enough of that. I look forward to the continuing discussion on common driver interface. As I learn more about EFI and read this discussion, I hope to add some dialog. Cheers! - Hypervista

I'd also point to OpenFirmware (http://playground.sun.com/1275/home.html) which superior to EFI in some ways. (Not least of which, it's been around long enough to be a proven, reliable solution with some decent industry support)

Greetings crc. Thanks for the link. I gave it a quick look and will go back for a detailed look over the weekend. I'm familiar with the OpenFirmware movement backed by Sun but will dig deeper on your recommendation. Thanks. - Hypervista