flat assembler
Message board for the users of flat assembler.
Index
> OS Construction > Help: An attempt at OS dev, again Goto page 1, 2 Next |
Author |
|
cypher 30 Apr 2011, 00:39
Yes guys, its me again. I posted something earlier when I requested some help for my OS's development (you can find it here).
Now, I'm back again and I've been planning to start developing an OS (without failing). I will take a somewhat professional approach where I will organize the development--technical documents and reference documents will be written; resources and reference manuals will be organized and so on. The scheme of the project is to reinvent the wheel. I want to create a DOS based OS that has the following: - filesytem (FAT16; instead of FAT12, because Tyler warned me about that extra nibble) - shell (CLI and maybe later GUI (which will be loaded like a regular program)) - program loader that supports DOS .exe and .com - drivers (keyboard and mouse) - software interrupts & system interrupts The kernel will be monolithic; according to Linus they are easier to write. The OS will be single-tasking. I will stick with real-mode and then maybe later I will enter protected mode (because p-mode is almost difficult especially enabling a20 line (in my opinion)). What I need to is get a push start and a pipeline of OS development so that I can follow it. My goal is to reach DexOS (well at least the first few versions). Can someone help me please? (Thanks in advance) _________________ When all in life fails, get weird and disappear into the mountains Last edited by cypher on 30 Apr 2011, 02:48; edited 1 time in total |
|||
30 Apr 2011, 00:39 |
|
xleelz 30 Apr 2011, 02:47
The best advice I can give you is to read OSdev.org for any information you need. If you do get to DexOS level and want to make your operating system grow, you might want to consider multitasking, paging, and making your own file system. I'm just now learning assembly language from the Intel manuals but I plan on doing those things after I am done.
_________________ The person you don't know is the person that could help you the most... or rape you, whichever they prefer. |
|||
30 Apr 2011, 02:47 |
|
bitshifter 30 Apr 2011, 04:47
Download Minix 3.1 sources and study them.
No sense in designing while still learning. |
|||
30 Apr 2011, 04:47 |
|
Dex4u 30 Apr 2011, 17:00
You can take alook at MiniDos its does must of what you want, other than fat 16.
Which you can add, as it freeware and you can mod it as you like. It can run exe and coms, it can run basic dos apps, but is only 2k in size. http://board.flatassembler.net/topic.php?t=5275&start=0 Or you can take a look at MikeOS which is very good and comes with great docs http://mikeos.berlios.de/ |
|||
30 Apr 2011, 17:00 |
|
cypher 09 May 2011, 10:45
Thanks, man! I almost forgot about MiniDos (btw, nice work, Dex4u!).
I'd be glad to mod it. Also, by reading the source and studying it, I could learn (similar to how I learnt about command-line interpreters by reading bitshifter's Console Fun. -- How did you go about designing and implementing? |
|||
09 May 2011, 10:45 |
|
Dex4u 09 May 2011, 16:19
cypher wrote: Thanks, man! I almost forgot about MiniDos (btw, nice work, Dex4u!). Your welcome, the main thing you need to know about MiniDos is that it users the boot loader code to load exe or com. When the boot loader (bootprog) is started it reloads its self to A000 - 512, this is how minidos load the exe or com file from the disk, it write the file name to load to the offset in the bootloader that store the name of file to boot, then jumps back to bootloader. On return from the exe or com it jumps back to the minidos kernel. You may think that this would mean the app are loaded at the same address as the kernel, but the load address in the bootloader is changed after the kernel is loaded. |
|||
09 May 2011, 16:19 |
|
cod3b453 09 May 2011, 17:41
First of all, I recommend you use a version control system. This can save you a lot of problems as things get bigger as well as help you manage changes. Popular examples are SVN, GIT and Mercurial.
Next, it's a good idea to get the full set of CPU manuals plus info for: - BIOS (see Ralph Brown Interrupt List) - CMOS (time/date) - i804x PS2 keyboard/mouse - i8053 PIT i8053 - i8259 PIC (possibly i82093 APIC) - VGA and/or VESA for video A filesystem is applicable to multiple controllers so you'll also want to find info for the type of drive you want to support e.g. floppy disk see i8272 hard disk see ATA (for SATA hard disk see PCI and AHCI) USB stick see PCI and [E/U/X]HCI. Finally, it's a good idea to have 2 or 3 virtual machines. Certainly, you will want two from Virtual Box, QEMU and Bochs but you can also use VMWare, VirtualPC and so on. I think that covers most of it (there's a lot more specific stuff you'll find as you go). One other thing I'd say is to not make your code too dependent on things like type of boot disk or optional hardware features -- I'm on my 3rd attempt since 2006; both times this was a factor as well as poor management covered by the above points. Hope that helps |
|||
09 May 2011, 17:41 |
|
cypher 14 May 2011, 16:08
Dex4u
That's some brilliant piece of coding. You mentioned that it loads to A000, right? What would happen if I wanted to do some something with graphics? Does the bootloader being at A000 affect graphic? cod3453 Yes, it helped alot. It gave me a kick-start! I think the manuals are most important at this stage. Those are of the wishlist. Talking about manuals--should I begin documenting? I selected SVN. I don't know the advantage of either of them, but most people appear to use SVN. Would it be possible if I created a repository and manage it myself; or would that just cause more complications--already having to develop an OS and all. |
|||
14 May 2011, 16:08 |
|
cod3b453 14 May 2011, 16:37
When to document is up to you; you can do it as you go along or after each "milestone" or whenever. If you're familiar enough with OS design you could also pencil out a basic roadmap of what you want to implement and when as well as a high-level design of the overall system.
You can create a repository on a local or remote machine. Both windows and unix have versions of svnadmin and svn command line tools but if you'd like something more graphical, you can get VisualSVN server for windows and TortoiseSVN client. Both are very quick and easy to pick up and do the job. |
|||
14 May 2011, 16:37 |
|
Dex4u 14 May 2011, 18:21
cypher wrote: Dex4u A000-512, Thats 512bytes below the the graphic address, as the boot sector is 512bytes. |
|||
14 May 2011, 18:21 |
|
bitshifter 14 May 2011, 19:26
Another good beginners os is MikeOS
Its written in NASM but is very close to FASM syntax. |
|||
14 May 2011, 19:26 |
|
Mike Gonta 14 May 2011, 19:52
bitshifter wrote: Another good beginners os is MikeOS The 32bit protected mode version of MikeOS (in FASM) is here |
|||
14 May 2011, 19:52 |
|
bitshifter 15 May 2011, 04:05
I see 32bit instructions but wheres the protected mode part?
|
|||
15 May 2011, 04:05 |
|
Mike Gonta 15 May 2011, 13:02
bitshifter wrote: I see 32bit instructions but wheres the protected mode part? Have a look at the original 16bit real mode MikeOS, you will see 16 bit instructions but no real mode part. That's because the native real mode BIOS has disabled the A20 (most modern PC's have the A20 enabled at boot), programmed the PIC and setup the Interrupt Vector Table providing handlers and drivers. This is what makes BIOS based system programming relatively easy, no complex setup or drivers are required. Looking at the 32bit version of MikeOS you will notice how similar the two are. It's just as easy to program a BIOS based system program in 32bit PM as it is in 16bit RM. Of course a 32bit PM BIOS based system program requires a 32bit PM BIOS. This is the function of aeBIOS. aeBIOS is loaded and initialized through the normal booting process. aeBIOS does not write to or alter the hard drive or BIOS firmware in any way. aeBIOS enables the A20 (if required), enters PM, reprograms the PIC and sets up all necessary tables. aeBIOS then loads a user supplied 32bit PM "boot sector" which typically loads a kernel file (in this case 32bit PM MikeOS). 32bit PM MikeOS has full unrestricted access to all memory (up to 4Gb) as well as access to the native motherboard BIOS through the standard BIOS interrupt interface. All hardware interrupts and system callbacks can be hooked in PM32 even if they occur during RM16. The default PM32 handler is to change to RM16 and execute the RM16 interrupt handler. Currently aeBIOS is distributed as a FAT12 floppy disk image. A custom boot sector is designed specifically for USB booting and a filter allows the code to run as floppy disk emulation even on PC's which boot USB as hard drive emulation. This simplifies development and provides a universal solution. Of course it will also boot and run from a floppy disk. I'm currently working on a paging interface and FAT32 support for aeBIOS which will be released soon. Last edited by Mike Gonta on 10 Jun 2014, 10:02; edited 2 times in total |
|||
15 May 2011, 13:02 |
|
Dex4u 15 May 2011, 15:43
[Of topic]
@Mike Gonta, I wish aeBIOS had been about many years ago, than i would not of need to code my OS. Have you any thoughts on aeBIOS and the new uefi type BIOS ?. Maybe you could turn aeBIOS into a loadable uefi driver for 32bit pm BIOS interface. |
|||
15 May 2011, 15:43 |
|
bitshifter 15 May 2011, 16:55
So how can you use BIOS interrupts which lie in the same
space as the reserved Intel exception handlers? (0-31) |
|||
15 May 2011, 16:55 |
|
BAiC 16 May 2011, 04:59
bitshifter wrote: So how can you use BIOS interrupts which lie in the same nothing special is required. you need to be aware that Intel won't care about breaking your code in latter processor revisions (Intel putting those vectors to use) so it's a 'use at your own risk' situation. whatever process you use for vectors above 31 are what you'd use for ones below 32. |
|||
16 May 2011, 04:59 |
|
cypher 19 May 2011, 08:01
--- Out of thread context. I can agree with the code reuse principle if you are very verse in programming, but what if you are an amateur (like I am). Would it be wise to reuse code (by someone else). For example, BootProg. Would that be a good idea? Also, what if you are learning to program an operating system. They guide you through the development and you must use the code that they provide. For example the tutorials at www.brokenthorn.com. I am learning to create a bootloader and all i must do is follow the tutorial and rewrite the code. How do I learn this way (especially on something this vast)? Do I write notes in a note book or do the tutorial more than one (boring)? How do you guys remember all of this information? --- Dex4u wrote: A000-512, Thats 512bytes below the the graphic address, as the boot sector is 512bytes. Understood. After scanning BootProg by Alexei's, I understand. MikeOS is a really inspirational OS. I'm rethinking the design. Minix is also good. All that is needed now is the book to complement it. But I have to buy it. æBIOS. Nice work. SVN? Is it possible to have an SVN on my own server? Is an SVN really necessary? I began writing the bootloader but I've become lazy and I'm thinking of using BootProg. It's less work. So I can get started on coding the kernel. But then again, by coding the bootloader I can get familiar with the filesystem and other things about protected mode. I am using the BrokenThorn tutorial (see link above) to learn about bootloaders. When I'm done coding it I will upload it here for some assistance from the pros. _________________ When all in life fails, get weird and disappear into the mountains |
|||
19 May 2011, 08:01 |
|
cod3b453 19 May 2011, 16:39
cypher wrote:
cypher wrote: ...Is an SVN really necessary? |
|||
19 May 2011, 16:39 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.