Milestones

[Mercury Thirteen]

To help keep us all on the same page with development, here we have set some major milestones for the project, along with the projected date when they will be completed.

These milestones are not all-inclusive; each will include more features than those listed.

Milestone 1 - by end of 2017 - Completed 12/6/2017
- Boot
- Enter Protected Mode
- Can read and write hard disk sectors using LBA
- Can manage basic hardware (timer, keyboard, etc.) interrupts
- Basic "dummy" memory allocation

- PS/2 keyboard support

- PS/2 mouse support

- RTC integration

Milestone 2 - by end of 2018 - Completed 12/26/2018

- PCI bus scanning to enumerate attached devices

- Device driver loading system based on PCI bus scan

- ATA/ATAPI driver

- Full trap/fault/exception handling ability

- Enumeration of MBR partitions

- File system driver subsystem

Milestone 3 - by end of 2019

- FAT16 driver

- Can enter Virtual-8086 mode to run 16-bit Real Mode code

- Functional physical memory manager

- Paging support

- Preemptive multitasking (kernel level)

- Multitasking on multiple privilege levels

Milestone 4 - by end of 2020

- FAT32 driver

- exFAT driver

- Can run .com programs

- Can run .exe programs

- Can run .elf programs

Future milestones - 2021 and beyond

- Enumeration of GPT partitions

- Supports Night app packages

- Basic kernel API (string routines, memory routines, etc.)

- Power management (APM, ACPI) support

legend:

green = complete

blue = started, in progress

grey = not yet started

[Mercury Thirteen]

On 9/7/2015 4:42 PM, Chelson Aitcheson wrote:

Nice work you guys have really made some progress in such a short time.
I am fairly tied up at the moment but I hope to contribute soon.

Thanks, we try lol

Seriously, though, no rush. I'm going through a bit of a busy spell myself. "Life happens" I guess lol

I'm looking forward to your contributions!
 

[Antony]

Hi,

Finally having a moment to look at this and I think the milestones are a bit out of sync, especially given that the project is protected mode in nature. I would propose the following:

Milestone 1:
- boots (done)
- enters protected mode (done)
- can read and write disk sectors (done)
- can manage basic hardware (timer, keyboard, etc.) interrupts (done)
- functional paged memory manager (in progress)
- interfaces to essential (keyboard, mouse, text mode video, etc.) hardware (in progress) (core drivers)

Milestone 2

- full interrupt/exception handling ability

- can enter v86 mode
- can load simple .com programs from disk
- can multitask at least two .com programs simultaneously

- beginning of kernel API

Milestone 3:
- fleshed out multitasking ability (can handle as many tasks as memory allows)
- add .exe support
- PCI bus scanning
- device driver loading system based on PCI bus scan

You will find that in order to handle multiple processes, NightDOS is going to need interrupt/exception handling functions in place. Once in 32-bit protected mode, there will int/exception switches to jump to V86 mode, perhaps even real mode. I think .COM and .EXE files can be handled simultaneously, but I won't press that issue, of course which flavors of EXE files are you referring to? DOS .EXE, OS/2 PM .EXE, Win16 .EXE, Win32 .EXE? Win32 console apps may be the easiest, but may require either trying to figure out the Windows API, or determining the license constraints of HXDOS and including the portions we would need into NightDOS.

Once again, I'm sorry for the lateness on this, just my quarter of a cent.

-T

[Mercury Thirteen]

Good input! I see I've missed a discussion or two since I haven't been checking in here regularly... shame on me lol

I updated the milestones per Tony's suggestions, which brought to mind the kernel API. We shouldn't need much, as we don't want to become another bloated Linux kernel. Off the top of my head (which may or may not be useful at almost midnight!) I figure we can pretty much just duplicate the DOS API and add a handful of functions which address new features in the kernel, like multitasking and threading, 32-bit disk access, etc. Things the kernel will need to do itself anyway. Everything else can be layered atop the kernel, no? The kernel can be at the highest privilege level with drivers right beneath it and apps at the lowest. I don't know how feasible it is (e.g. I haven't given it more thought than a passing notion and a nod to myself saying, "yep, that should work") but I want to make everything a driver. The PCI bus, devices, file systems... everything.

Or, maybe this will do nothing but open up a coding nightmare.

[Antony]

There should be actually two parts to the kernel, a portion that represents the MS-DOS kernel (so that existing DOS applications can run) and the true NightDOS kernel. All DOS system calls should map into the NightDOS kernel, such that Int 21H function 00h (which is the superceded DOS terminate program) should reference ND_TerminateProcess.

The DOS real mode version would accept and return the values that DOS applications expect, but internally would call a NightDOS function to carry out the procedure. 

At some point, a decision should be made on which version of DOS NightDOS will emulate. Windows XP/Vista/7/8 all emulate DOS 5.0.

[Antony]

Hi,

You can't reply via email to these posts, so here's what Maarten emailed me:

Hi Antony,

Two In one? Will it both be 32-bit? Maybe if we can do one 16-bit and the other 32. Then we have solved the 16-bit uncompatible (sorry for my English) part. But we need to switch everytime to 32 and 16-bit. But we can do one 32-bit kernel and if we have an app/game then we switch to a 16-bit part, after we are finished we switch back to 32-bit.
I don't know all interrupts so I don't think we are 100 procent on the same page. But I think this is maybe a solution or at least a 'push' to the right direction.

Maarten

Let me clarify what I mean. NightDOS is going to provide it's own API to access devices, read and write files, etc. The NightDOS API won't exist at real mode INT 21H (although it may exist at an INT 21H). DOS applications can't access protected mode interrupts, so in order to run a DOS application, NightDOS needs to switch to a virtual x86 mode (V86) that emulates real mode (for the DOS app) but is still in a protected mode environment. In this V86 environment, NightDOS has to create what appears to be a MS-DOS environment, complete with the memory mappings for ports (from the BIOS) and MS-DOS structures and BIOS interrupts. Therefore NightDOS has to emulate the complete x86 DOS environment, complete with hardware and BIOS calls.

DOS applications will expect to be able to call INT 13H for example and access disk functions. Those disk functions aren't covered by DOS, but handled by the BIOS. NightDOS will have to trap those INT 13H calls and map them to protected mode disk calls. The same for INT 16h for the keyboard, and so forth. In addition, applications that properly use DOS to handle input and output, for example INT 21H/09H - WRITE STRING TO STANDARD OUTPUT would need to map to ND_OutputText. ND_OutputText will probably terminate with NULL, however INT 21H/09H terminates with a $, which is functionality we can't change.

Hopefully you see where I'm going with this.

[maarten]

yep, that worked...

Thank you!

and sorry for being wayyyyyy to late for this!

Maarten

[Mercury Thirteen]

We may as well support 5.0 as well then, unless there's some major advantage to supporting things from more recent versions of the API.

Also, the maybe it should phased in in steps so that we first implement support for the MS-DOS 1.10 API, then 1.11, then 1.14, etc. Also, that may be more trouble than it's worth.

[Antony]

Hi,

The DOS API is pretty consistent and mostly deprecates over the lifetime (i.e., use of file handles over file control blocks, IOCTL routines vs IO routines). Besides, depending on the call from DOS, a lot of IO will be (or should be) handled through the NightDOS kernel directly by intercepting the DOS API call, processing it, and immediately returning. Most of the calls that will requires some major lifting will be the file system and memory management calls because special protections have to be put in place to simulate single user access to the file system or single task application running in a multi tasked environment.

[Maarten Vermeulen]

I'm reviving a very old threat, sorry. But I want to make a suggestion: for milestones there is some sort of platform, I use it a lot. It's called Trello.
It's very helpful you can make to do lists 'cards' you can sort it on your own category's and you can make labels to make them recognizable. Also, you can assign people to a specific card. I think it's very useful. Maybe that's easier.

You do need an account, but you can make the board team-only/private and public.

Example (don't mind the goals), click on it for a big picture:

It's easier then using this threat, but it's just a suggestion. :D

I can make a team for this and a board...