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? | ||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
Total Votes : 23 |
Author |
|
Mac2004 13 May 2005, 05:42
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 |
|||
13 May 2005, 05:42 |
|
smiddy 13 May 2005, 09:54
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.
|
|||
13 May 2005, 09:54 |
|
f0dder 13 May 2005, 12:06
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.
|
|||
13 May 2005, 12:06 |
|
Scanner 14 May 2005, 11:37
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. |
|||
14 May 2005, 11:37 |
|
THEWizardGenius 15 May 2005, 23:04
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! |
|||
15 May 2005, 23:04 |
|
crc 15 May 2005, 23:51
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. |
|||
15 May 2005, 23:51 |
|
THEWizardGenius 17 May 2005, 14:05
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
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! |
|||
17 May 2005, 14:05 |
|
smiddy 18 May 2005, 11:52
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!
|
|||
18 May 2005, 11:52 |
|
tom tobias 05 Oct 2006, 16:50
Smiddy:
Quote:
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. 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! |
|||
05 Oct 2006, 16:50 |
|
smiddy 06 Oct 2006, 03:53
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. 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! |
|||
06 Oct 2006, 03:53 |
|
tom tobias 06 Oct 2006, 10:52
Quote:
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 |
|||
06 Oct 2006, 10:52 |
|
vid 06 Oct 2006, 11:28
smiddy: so, could we see your code? i would really love to know at least...
|
|||
06 Oct 2006, 11:28 |
|
smiddy 06 Oct 2006, 13:58
@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... |
|||
06 Oct 2006, 13:58 |
|
vid 06 Oct 2006, 14:02
just a page of code... pleaaaaaase
|
|||
06 Oct 2006, 14:02 |
|
smiddy 06 Oct 2006, 14:09
I'll see what I can share that is ready for this forum, once I get home this afternoon.
|
|||
06 Oct 2006, 14:09 |
|
vid 06 Oct 2006, 14:36
thx
|
|||
06 Oct 2006, 14:36 |
|
Niels 06 Oct 2006, 16:43
(w)right(e) what you need.
Niels. |
|||
06 Oct 2006, 16:43 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.