Jump to content
  • Advertisement

Crypter

Member
  • Content Count

    1299
  • Joined

  • Last visited

Community Reputation

748 Good

About Crypter

  • Rank
    Contributor
  1. Thank you! 20 chapters has gone by in the OS development series. A little over a year sense it has started on this very site. I want to give a public thank you to everyone - it is the support that I get from readers and members of communities that helps keep the series going. Thank you everyone!! OSDev Series Chapter 20 Chapter 20 has been officially released. It covers: FDC and FDD History Disk Layout CHS and LBA FDD Structure FDC and FDD Hardware Interfacing with the FDC FDC Registers and Commands Programming the FDC It also now includes a demo that is built from the Textual User Interface (TUI) that we have built from the previous chapter. We build a floppy driver in this demo, and impliment a read command to allow us to read from any sector on disk. Check it out here. Please feel free to let me know if there is any comments or suggestions! OSDev Series Updates - Revision 3 I have also added navigational icons to the chapters of the series to help making navigating the series easier for the readers. More updates for the series are also planned including bug fixes, additional content, and more as I impliment Revision 3 of the OS development series.
  2. OSDev Series Chaoter 20 I cannot believe it... I am at chapter 20 of the OS development series going on to chapter 21. It all started with a forum post here on GDNet and is continuing on thanks to the great support that it gets. I thank all of the supporters of the series [grin] Chapter 20 covers almost everything about floppy drive programming including: FDD history Disk layout CHS, LBA FDD Structure FDC Hardware FDC Registers and Commands FDC Interfacing FDC Programming The demo adds a read command to the TUI demo developed in the last chapter that allows you to read any sector on disk using the floppy driver developed in the chapter. OSDev Series: Chapter 20 OS Dev Series Base Site If anyone has any questions, comments, suggestions, or ideas, please feel free to let me know [grin]
  3. Crypter

    Small update on Neptune

    Neptune Kernels new Debug Screen - Running in VPC Hello everyone, This is just a small update on Neptune. I have finally gotten native Win32 compatible resources implemented in the kernel. (Well, just images anyways but still [grin]) Thanks to this, the kernel can now use bitmaps for different things without loading anything from disk. This also makes development easier as we can just use an image program and resource scripts [smile] Also, thanks to boot time DLLs, the kernel itself is still a microkernel and has no internal drivers for anything. DLLs are used by the kernel but are separate programs. With these additions, the kernel is still being cleaned up to better fit the new design. I suppose thats all for now [smile] I know it somewhat looks like Windows XP do to the colors. What can I say? I like those colors [grin] I am always looking for suggestions though if you have any!
  4. Crypter

    Neptune Updates

    Hello folks, this is just a small update on Neptune! We have been working on Neptune a bit in the last few weeks. The Kernel now supports native Win32-complaint bitmap resources. Thus we can create images in any image program and create a simple resource script to compile into the kernel for it to work [smile] I really like this current setup as it allows the kernel to work with resources without needing to load anything from disk. And do to it using a VGA DLL, the kernel itself doesnt do anything at all with hardware so it follows a microkernel design. With regards to the colors; they do look alot like XPs. What can I say, I like how they look [grin] but if anyone does have any suggestions please feel free to share! I guess thats all for now [smile]
  5. Crypter

    Neptune Boot Loader 2.0

    Hello everyone, I have gotten the 2nd rewrite of Neptune Boot Loader complete. Thanks to the new Boot Library, the boot loader itself took only two days to make [smile] It is capable of booting multiple operating systems through an LST file (which is basically an INI file in disguise.), and a dynamic boot menu. Supports any mountable volume and filesystem that the boot library nativity supports. About 6,000 lines smaller then the previous version as well thanks to the boot library. Click here for a snapshot and the documentation on the new and improved boot loader [smile]
  6. Quote:Original post by O-san I which I understood half of those abbreviations but I am very impressed by your work nonetheless. Is the OS going to have graphics or is it more sort of text-based, like DOS? Neptune is graphical. The OS for the series I do not know yet.. I may cover a basic graphics tutorial for the series OS as an "Advanced Topic" rather then fully integrating it with the series as its not really a beginner topic. I am still considering it though and am always looking for opinions on it [smile]
  7. Hello everyone! [smile] I know that I should start posting more often again - I have been very busy with work and my projects. I have still been visiting this site every day though. I am hoping to get back to a regular posting schedule soon, I promise! [grin] OS Dev Series Chapter 20 - FDC Programming The 20th (Yes, 20th!) installment has been released. I plan another update very soon which will include a demo. This chapter looks at: FDC and FDD History Disk Layout CHS, LBA FDD Structure FDC Hardware Interfacing with the FDC FDC registers and commands This chapter can be reached at here (Clicky!). Please let me know if there are any comments or suggestions! I am still thinking of what should be next. I am considering between DMA and a C FAT12 minidriver chapter. I don't like filesystem programming so I may go DMA first [wink] Update - Neptune Boot Library The Neptune Boot Library helps reorganize the way Neptune boots and loads. It provides a very portable and hardware independent way of interfacing with display (text output), loading files (abstract filesystem access and volume mounting), PE loading, dynamic library loading, generic disk access, and a standard method of error handling. I originally got the idea from Windows Vistas booting design. The Boot Library interfaces with the system BIOS (or can be extended to support EFI) and is written in C. Only one function - io_services () - is architecture dependent do to its usage of the system BIOS. It also supports INI and Neptune LST configuration file parsing through a standard function very similar to the Win32 APIs GetProfileString () method. This library makes it very easy to develop C boot loaders and startup applications using Microsoft Visual C++ 2008, or any compilier (hopefully) that can support Win32 compliant PE executable images. I am still considering if I will release this library to the generic public or not though... It certainly makes things much easier and reduces code duplication alot. I suppose thats all for an update for now. As always any comments are welcome! [grin]
  8. Crypter

    Project Neptune

    Make backups now! I have lost almost 600-800 lines of code this week do to an annoying thing that happened in Visual Studio. I copied two files from one project to another thinking that they were truly copied...Then I deleted most of the contents of the copied files (they were not needed in the new project), saved them, and closed them. Wondering where my other errors are coming from, turns out I basically ruined both copies of the files. Ugh! To make things worse: I could not get them back or revert the changes. The good news is that I did have a backup a few weeks ago and was able to recover from it. Always remember to make backups often! You never know what might happen!! Change in codename "MicroOS" and "mos" seem to be fairly common codenames for "Microcomputer operating system". In an effort to stand out a little more I decided to drop this codename and remove "OS" part completely. As of current, the new code name is Project Neptune. Boot.ini The boot loader now has (almost) full support for working with boot time scripts. This allows us to manually configure how we want to boot; boot time options; boot types; and additional commands dynamically. All of the internal command parsers commands are supported. There is no special reason why I named the file "Boot.ini"...I just cannot seem to find a nice name for the file besides the above. If I name it "Boot.scr" for "Boot script", Windows will think its a screen saver :p If anyone here has any suggestions, feel free to share. [smile] New TUI I have also upgraded the TUI to something a little more pleasant to the eye and (hopefully) more user friendly. I suppose that's all for now. ...Been a busy week.
  9. Crypter

    OSDev Series: Chapter 19

    Yes, I do plan on publishing it. I hope it turns out well [smile]
  10. Crypter

    OSDev Series: Chapter 19

    Are these questions related to the series or my real system? If the series: 1) No idea :) Im uncertain if I will go over those do to portability issues and the complexity of both topics; 2) All i86-32 bit compatible processors If my real system: 1) The drivers will be implemented as multiple layers that interfaces with the systems graphical and audio sub systems. These sub systems provide a more abstract and portable way of working with graphics, audio, windowing systems, etc. 2) Hopefully all. That is, I am designing and writing the software in a very modular way using C++ and its OOP features. I am hoping the use of abstract classes and methods can aid in portability for different implementations for different architectures that can be selected at preprocessor time. The Hardware Abstraction Layer (HAL), being loaded dynamically I am hoping can help aid portability across PIC/APIC systems, single-core, SMP systems; and other motherboard-dependent architecture features. My primary goal is portability [smile]
  11. OSDev Series: Chapter 19 Chapter 19 has been released. There is no demo yet, but it should be released within a day or two (hopefully). It covers: Keyboard History Keyboard Layout Keyboard Protocols Keyboard Encoder Keyboard Controller Scan Code Sets Keyboard IO Port mapping; Commands; Interfacing Keyboard IRQThe demo is also the first interactive demo in the series. It uses the new keyboard driver developed in this chapter to interface with the user through a Command Line Interface (CLI). Chapter 19: Keyboard Programming OSDev Series Base Site As always, any input is always appreciated [smile]
  12. Crypter

    MoS Boot Loader

    MoS Boot Loader Hey everyone! [smile] I have rewritten my systems bootloader from scratch to provide more flexible way of booting either MoS or existing operating systems, with better support for BIOS or EFI booting from different boot devices, filesystems, and architecture abstractions. Of course, there is GRUB and LILO; but my goals are different which is why I have developed my own. Here we are. 11K lines of code later and the main menu has just been completed. I figured that I have not posted in a little while, so why not? Heres the new boot menu: This is with the second option selected (and enter pressed). Because its not a valid system, it displays an error. This is just a test to insure the menu rendering code worked fine. Highlighting and selecting the first option brings the user into the internal command interpreter (Which almost none of the commands are implemented yet. Im still trying to determine how I should proceed from here) : I got the idea of the internal command line from GRUB (Which I would like to see BOOTMGR have as well.) Im thinking of having the bootloader look in the current boot drive for a MOS.INI file and running it as a boot up script if it exists to determine how to boot. MOS.INI would contain the operating system options that would be displayed in the main menu (Which is dynamically rendered). Currently, it only supports reading from FAT12. However future support for FAT16 and FAT32 are planned very soon as well as partitions. The current design of the boot loader software already has partitions in place; just not fully implemented yet. Written almost entirely in C++ and designed kind of like NTLDR and BOOTMGR I am very happy with the current progress of the bootloader so far. [smile] Now, back to coding...
  13. OSDev Series: Tutorial 18: Virtual Memory Management Sometimes these tutorials just get fun to write [wink] Tutorial 18 covers alot of topics including: Virtual Memory Memory Management Unit (MMU) Translation Lookaside Buffer (TLB) PAE and PSE Paging Methods Pages and Page Faults The Page Table The Page Directory Table Implementing Paging It develops a virtual memory manager that manages and provides an effective interface for managing and working with pages, page tables, page directories, and virtual memory in general. OS Development Series: Tutorial 18: Virtual Memory Management I will be updating the tutorial with some more content and the demo within the next couple of days. Until then I am wanting to hear feedback on readability, ease of reading, and ways to improve both the text and code within the tutorial. Please let me know what you think! This tutorial builds off the physical memory manager build in the previous tutorial.
  14. Yeesh! Today has started out as a typical day of programming. After making some modifications to the code to fix some warnings and split the code into smaller routines, I rebuild and test. invalid instruction! Okay I thought. Ill just undo the changes and try it again: general protection fault! Eek! At this point I was having no idea what was going on. The code worked fine for weeks without any problems; what can cause this to happen now? I decided to go back even further to see if it was any of the newer code: invalid instruction! *ugh*. After going through my code, I found out I was working with a pointer that was never initialized. The system uses a single singleton class called core that provides a basic set of routines that need to be used across all other classes. Thus everything uses it. All of them obtain the pointer from this routine: core* core::get () { return m_core; } Keep in mind that this is self hosted running in ring 0. And all classes are using m_core to print strings, call bios interrupts, and more...and it worked fine for weeks until now. The fix for it was simple--just have m_core point to a known valid address. Not having a memory manager nor wanting to point to specific locations in memory, I decided to have the compilier do it: core* core::get () { if (!m_core) { static core pkCore; m_core = &pkCore; } return m_core; } After this change everything seems to be working fine now. I have no clue of how this managed to work before just fine (even on raw hardware) without any problems :/ I am glad the problem turned up now though before it became a bigger issue! If anyone knows how it managed to work for weeks ill give you a free cookie [wink]
  15. Crypter

    MoS's merger.exe

    Alright... My systems boot loader consists of two separate programs. The first is a 16 bit/32 bit flat binary assembly language program (startup.sys). The second program interfaces with the first--its the bulk of the bootloader and is a 32 bit MSVC++ program. (OSLoader.exe). The problem here is that we are trying to abstract the filesystem the bootloader is using behind a common interface. However it is not really possible to do this inside of startup.sys (Although it is possible in osloader.exe). So, what I wanted was a way to take the file loading code completely out of startup.sys. I wanted a nicer way for this to work. So I decided to create a small program that will generate an image similar to Windows NTLDR and BOOTMGR. It can combine any number of files into one--I call it merger.exe. Using our new merger.exe program, I updated the boot code to allow it to work as a single image file: Behold! MoS's KRNLDR boot loader! Now KRNLDR consists of both startup.sys and OSLoader.exe all in one file. Startup.sys has also been stripped of all loading code as it doesnt need it anymore because OSLoader.exe is directly after it in memory. Thus the only disk read/write code (and the only filesystem code) is in an abstract set of classes within OSLoader.exe. While the system itself is closed source, Im leaving merger.exe to the public in case anyone is interested in it. There are a few problems with it, but for the most part it seems to work fine for my needs. The command line for it is merger.exe outfile.bin file1 file2 file_n, where merger.exe is the programs name and outfile.bin is the output file location. #include #include #include //! program name const std::string _strProgName = "merge.exe"; //! program interface class prog { std::fstream m_fOut; void display_parm_help (); public: bool init (std::string& fIn); int run (int argc, char** argv); virtual ~prog (); }; //! display help info if incorrect command line is used void prog::display_parm_help () { std::cout
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!