flat assembler
Message board for the users of flat assembler.

Index > OS Construction > How should I do this?


What order should I write the code in?
All Drivers First (pmode last)
0%
 0%  [ 0 ]
Minimal drivers first (pmode next)
17%
 17%  [ 4 ]
No drivers first (pmode first)
78%
 78%  [ 18 ]
Other
4%
 4%  [ 1 ]
Total Votes : 23

Author
Thread Post new topic Reply to topic
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
I am planning to write a 32-bit protected mode OS, eventually multi-tasking (though that is out of the question for now), mostly if not all, in assembly.

My question is this: Should I write the protected mode code first, and then the drivers, or should I write minimal drivers (CGA/EGA/VGA and keyboard and floppy disk) first? I'm guessing it's gonna be protected mode first, but I'm wondering what your opinons are. Of course, after the Protected mode code is done I will write Mouse, Soundcard, Parallel and Serial printer and communications, Hard Drive, and all the other important drivers first. I know how to do most of this stuff- I just don't know what order I should do it in. What do y'all think?

_________________
FASM Rules!
OS Dev is fun!
Pepsi tastes nasty!
Some ants toot!
It's over!
Post 13 May 2005, 04:33
View user's profile Send private message AIM Address Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
I would prefer to have pmode working before trying to implement drivers. You would have your own OS enviroment for testing whether your driver code actually work under your own OS or not.

regards,
Mac2004
Post 13 May 2005, 05:42
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
I think you run into the chicken or the egg syndrome no matter what you do. My vote was minimal drivers (just to get things working, like screen updates and pre-loading drivers). That being said, you need to have the ability to remove and replace that driver when you eventually get into protected mode. This is precisely how I'm doing my own setup. I'm currently at the protected mode driver development stage. It looks promising from my perspective, but then again I'm an optimist. Wink
Post 13 May 2005, 09:54
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
If you want to do anything serious, start with working pmode, interrupt handling, memory allocation, process/thread and scheduler stuff - then focus on drivers. Of course there's the chicken/egg stuff, so you'll need to write some keyboard and screen routines as you go along... but don't spend time on other drivers until you have a working and stable kernel.
Post 13 May 2005, 12:06
View user's profile Send private message Visit poster's website Reply with quote
Scanner



Joined: 14 May 2005
Posts: 7
Scanner
Quite simple: Developing and testing protected mode drivers/ISR's etc. is close to impossible if you have nothing developed already (i.e. working bootloader, working screen driver, working keyboard driver). You need these components as a minimum to troubleshoot bugs in your drivers. Getting these to work is a mission on its own because of implied complications with setting up the IDT, GDT, PIT, PIC and all components that are required at minimum to allow you to have a screen and keyboard driver. Believe me, setting up the GDT and IDT properly is difficult especially with all the incomplete material out there. Troubleshooting a tripple fault because of an incorrect GDT entry takes forever because you don't have a console to print the GDT to for inspection.

I suggest you use a 16 bit compiler (TC/TP) to create the general structure and working versions of the drivers you intend to port to protected mode. Once the 16-bit version has been tested, it is a lot easier to test and implement 32-bit versions.

You will encounter a lot of situations in which you can't determine if the bug is in your code, the virtual machine used for testing or if the hardware is acting up. The only way to eliminate the last two factors is to get a working version on the emulator with the emulated/physical hardware. That way you know the bug is in your driver (pmode) code.
Post 14 May 2005, 11:37
View user's profile Send private message Yahoo Messenger Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
Thanks folks.

I think I should maybe do the minimal drivers, like screen and keyboard, but of course I will need to write new 32-bit ones once I get the pmode code. The minimal drivers (probably only screen and keyboard) won't take much time, and I can get started with the pmode code afterwards.

_________________
FASM Rules!
OS Dev is fun!
Pepsi tastes nasty!
Some ants toot!
It's over!
Post 15 May 2005, 23:04
View user's profile Send private message AIM Address Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
I'd recommend not doing any 16-bit drivers other than a basic wrapper for the BIOS screen and keyboard routines. Writing the drivers for a purely protected mode, 32-bit environment is a lot easier than doing the same for real mode, 16-bit code.

My path was to have a small set of functions to display messages during the bootloader phases, then I wrote a keyboard and text screen drivers for the kernel (protected mode). My keyboard code is pretty small, but the video driver is quite a bit larger. (Very nice and reliable though). After this, I implemented hard disk I/O, then serial, parallel, and others.
Post 15 May 2005, 23:51
View user's profile Send private message Visit poster's website Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
Speaking of Serial and Parallel, I'll probably do those first (once I finish the pmode code) since they are the easiest things to do Laughing
But you probably have a good idea. I might write a display driver, but I might just use BIOS (since I won't be in pmode yet), but I don't want much else. So complicated, especially when you have the chicken-and-egg thing- speaking of which, I got a great idea: make a sort of flowchart diagram of everything you'll have in the OS, especially drivers, and then you'll know what you need.
Example:
-Printer Drivers (ESC/P2, PCL, etc.)
-Requirements: Parallel drivers and Serial drivers (for rare cases with serial printers)

This is how I figure out what to do and when to do it. Of course, some things you will need to plan ahead for. When making a driver that depends on something that depends on it (chicken-and-egg) decide how you will write both drivers ahead of time, and program so that when both are finished, they will work properly together (probably a few adjustments and extra code will be needed, of course). Of course, this is all just theory: time for me to get started!

_________________
FASM Rules!
OS Dev is fun!
Pepsi tastes nasty!
Some ants toot!
It's over!
Post 17 May 2005, 14:05
View user's profile Send private message AIM Address Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
I worked on a serial port driver around 1990-ish and didn't think it was all that simple. I understand more now though and expect that I'll grasp the communications concepts better. Good luck!
Post 18 May 2005, 11:52
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Smiddy:
Quote:

I'm currently at the protected mode driver development stage.
Aaron, your snippets of program posted at another forum are very well written. Great explanations with good documentation, very instructive.
Shortly after this quote above, from last year, you wrote (describing the prospects of protected mode driver development):
http://board.flatassembler.net/topic.php?t=3855
Quote:
Nah, it isn't harder. It is more time consuming since there are more opportunities for performance and features.
responding to a forum query regarding the writing of protected mode code first, versus writing real mode code, for video display, then switching to protected mode.
I wonder if you have the same assessment this year, noting that you appear, to me, to be displaying the results of your initialization process on the screen, in real mode, then switching to protected mode for the prompt. I am very impressed with your writing, and hope you will continue to show us examples from time to time, it is really encouraging to find someone who communicates what they are doing, or even, as in your most recent example, explains what they are struggling with, and the methodical, step by step approach employed to solve the problem responsible for the struggle. Great work!
Smile
Post 05 Oct 2006, 16:50
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
Tom,

You really drug the bottom out of the river with this post, but I concur with your assessment. What you are seeing is my dynamics. I consider what I do here strictly a learning environment. In order to learn you have to plan your learning or hypothesis. My determination from visualizing to reality forces my output. Along the way announcing these ideals puts me into that frame of mind. Thus I share.

Now, with regard to the display on my OS. The over simplified version of it is I am creating the OS' Device Manager. Some of which is done in real mode, but some of it has to be done in protected mode. Some of the protected mode is 24-bit too, which adds to the complexity. So a natural question might be, why not do it all in one or the other modes? As I pointed out above, I use my OS to learn. In order to do that I put (perhaps) undo complexity onto my own requirements to see if I can do it. Partially since there are so many nay-sayers out there who don't beleive something can be accomplished I put some time into proving that wrong, to my own amusment.

I suppose you could say my philosophy towards my hobbie leans on the side of determined optimism. Or the 'I think I can' principle. Wink

Unfortunately I am not doing anything too new within the management of my own OS, yet. When I do I will announce it here. As an FYI I have finished a basic ATA(IDE) driver (and FDC) this evening with success. I am primed to work on a HDD boot sector for 16-bit FAT (first). Once that is employed I beleive I will be able to start adding executeable programs outside of the OS.

I appreciate the complement, thanks!
Post 06 Oct 2006, 03:53
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Quote:

the bottom out of the river with this post

Well, and I can appreciate that one can misquote, or extract quotes out of context, and for sure that was not my intent. What was my intent?
Many, MANY members of this forum find my posts not only monotonous (always harping on "readability",) but also IRRITATING, and sometimes, as with "Ms.Taken", deliberately so, as a provocation, following Hegel's lead in challenging people's way of thinking... Umm, but, in this case, I was not trying to dredge up old mistakes, or old errors, or old faux pas, no. NO, I was simply trying to place your newest efforts in context, i.e. to show how your efforts over the past couple of years have evolved. I remain very impressed with your accomplishments, not only the executable, but particularly the SOURCE code, not yet visible on this forum, (sadly, because lots of folks on this forum NEED to learn how to write EXPLICITLY, instead of CRYPTICALLY, as most here do, in my opinion, notwithstanding their status as educators in training, i.e. graduate students--future instructors to be--or with a tendency to deliberately write code with obfuscation, as some misguided souls on this forum do with pride!!!)
Quote:
I have finished a basic ATA(IDE) driver
Wonderful. I will stop everything else, to install it on its own partition, once it is available....Thanks again for your candor, enthusiasm, and genuine contribution. Have you had an opportunity to compare your nascent accomplishments with Octavio's, or Christoffer's or anyone else's?
Smile
Post 06 Oct 2006, 10:52
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
smiddy: so, could we see your code? i would really love to know at least...
Post 06 Oct 2006, 11:28
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
@vid: My intention is not to release it until I have finished 1.00, that really means the list of ToDo's needs to be completed. I don't have the complete list here, but it includes:

ATA and FDC drivers (nearly complete)
Device Manager (for installing and uninstalling device drivers, without rebooting.
Text Windowing Manager (I can get screens to 160 x 64, though buggy)
Logical Block Manager (though limited to FAT 12/16 for 1.00)
Ethernet Manager (OSI model layers for the kernel; drivers interface with this)
File System Manager (FAT 12/16 only for 1.00; 2.00 has plans to implement many more)
8139 Ethernet Driver
Pre-emptive Multitasking (Software scheduler)
FORMAT (12/16 Fat for 1.00)
CHKDSK (12/16 Fat for 1.00)
NETMON (basic monitor; no translation just data)
Tetris Game (In work)

That about sums it up for now. Other drivers are/may be needed in order to facilitate the above. Once this is all done, I will release the source.

@Tom: Several things come to mind that I can say about other people's code; as to why. But I will not. My own conviction is that I realize I do not retain everything, therefore I have to make it as readable as possible. One thing I couldn't stand in taking science related courses is that the books used, for example, math to get to an answer but often times would skip several steps in getting to the ultimate answer. Most times by saying, "Obviously" this is your answer, when in fact it wasn't so obvious. I think if you work on something long enough you will ultimately forget what you did and why. Specifics on how and why are important when you go back to your work later to reintroduce yourself to it. Does it consume time initially, sure, but it will ultimately reduce you re-education time by being clear, at least from a selfish perspective.

I have seen bubach's and Dex's and they are very comparable. I haven't delved into Octavio's OS. I may give it a look-see this weekend. However, I don't think a cursory overview is what you're looking for, but more a critical analysis of their works? I am so engaged with my own neophytic OS to do either of them justice in review. But perhaps I shall...
Post 06 Oct 2006, 13:58
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
just a page of code... pleaaaaaase Smile
Post 06 Oct 2006, 14:02
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
Wink I'll see what I can share that is ready for this forum, once I get home this afternoon.
Post 06 Oct 2006, 14:09
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
thx
Post 06 Oct 2006, 14:36
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
(w)right(e) what you need. Smile

Niels.
Post 06 Oct 2006, 16:43
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.