Official dev thread

[Mercury Thirteen]

Since we're notifying each other any time we push code updates, I figured a dedicated thread for that was in order. So here it is.

But it's not just for code pushes! This will be our place to discuss the current state of the kernel, regardless of where it is in its life cycle. If one of us gets stuck on something, added some new code or whatever, here's the place to talk about it.

[Mercury Thirteen]

Why not be the first responder to your own thread, eh? :)

I pushed updates to kernel.asm and gdt.inc which fixes some things, adds some features (you can now specify where on the screen to place the text in the Print function) and initializes the programmable interrupt controllers. Interrupt handling is next on my list, namely the keyboard and the timer tick interrupt. It's time this kernel got a heartbeat!

The code assembles and runs, so there's that. Goodnight.

[Mercury Thirteen]

Interrupts are now working. I added an interrupt call to the infinite loop which repeatedly fires interrupt 0xFF. The handler picks up the call and increments a counter value at 0x500. Everything runs with no errors, so that's always a good thing. :)

I have all the hardware interrupts currently masked off, so next I have to start implementing handlers for them. Keyboard, timer, etc.

[maarten]

Yes nice!

Sorry for the delay.....

i will also take a look at it :)

and i'm also gonna do something.  :D

[Mercury Thirteen]

On Sun, Aug 2, 2015 at 10:32 AM, Jayden wrote:

Is there anything you need me to program?

Sure, help is always needed! :)

The only problem is, at this early of a stage, there's not much to built upon yet. We have no disk access functions, no video functions, no string routines... etc.

You could pick any one of those, or if you'd rather wait until I have the keyboard interrupt working, you could write the keyboard handler. There's so little written right now, anything you want to contribute would be useful.

[Mercury Thirteen]

No worries, I of all people know what it's like to be busy and delayed lol

I look forward to your contributions :)

[maarten]

i'll do the keyboard...

[Mercury Thirteen]

I'm going to do a commit in a moment for you guys to look through. This iteration of kernel.asm will be different in that I assigned a different interrupt handler to each interrupt from 0x00 to 0x2F, which encompasses all the internal interrupts the CPU may use and all the IRQ lines from the PICs. Each handler increments a byte value from 0x0500 to 0x052F to correlate with the range of hardware interrupts. By dumping the memory at 0x0500, you can see which interrupts were called by noting the memory position of bytes which are non-zero.

This code has the IRQ interrupts remapped to 0x20 - 02F, so as soon as interrupts are enabled a pulse of the timer should fire interrupt 0x20, however it is actually firing number 0x08. This means the PICs are not responding to the remapping code and are still firing the default values they are programmed with from the BIOS. The question is... why? By all accounts I can find, the code is correct and feeds the PICS with the data they're expecting for the remap... I'm kinda at a loss for the moment. Maybe you guys will see some stupid little detail I'm missing.

[maarten]

where is the updated kernel then? (if you've done that today)

[maarten]

oh! nevermind :)

[maarten]

one little question though, where do you want to use "PICInit" for? :D

[Mercury Thirteen]

I haven't yet... keep getting sidetracked lol

I'm about to here in the next few minutes.

[Mercury Thirteen]

The update is now in the repo.

PICInit is the routine which sets up both Programmable Interrupt Controllers. When you enter protected mode, there's a conflict between the hardware IRQ default handlers and the exceptions used by the CPU, so you need to remap the PICs to fire interrupts that are above the CPU exception range and therefore won't get in the way and cause a conflict.

[Mercury Thirteen]

On Mon, Aug 3, 2015 at 8:59 PM, Jayden wrote:

I can't seem to figure this out....where is the source code? Is there a link for it?

 
You can find the files at: https://github.com/mercury0x000d/NightDOSKernel/tree/Development/src/KERNEL

You'll need gdt.inc and kernel.asm if you're going to build the kernel.

[Mercury Thirteen]

On Mon, Aug 3, 2015 at 10:11 PM, Jayden wrote:

Thank you.

No problem!

I should point out that software interrupts work flawlessly - only the PIC-controlled hardware interrupts have this issue.

[Mercury Thirteen]

I'm pushing the latest kernel to the repo. The IRQ issue is fixed (Maarten, you can start the keyboard handler now!) and we now have a timer tick interrupt and can also print hex numbers to the screen - a useful debugging tool! I reduced parts of the growing kernel.asm into a couple other .inc files.

[maarten]

i suppose we need all the three .INC files? :D

[Mercury Thirteen]

On Wednesday, August 5, 2015 at 10:57:01 AM UTC-4, maarten wrote:

i suppose we need all the three .INC files? :D

Yep. The kernel is now comprised of:

kernel.asm
gdt.inc
setints.inc
inthandl.inc

[maarten]

ok thank you

:)

[maarten]

Hi all,
Should I throw the "alt+tab" in already or do we want to wait with that?
Also after the keyboard handler, what needs to be done next? (Just for orientation) :D

Maarten

[Antony]

Next should probably be the file system or the virtual memory manager. At

some point, NightDOS will need a C compiler and C runtime.

I know some of us are "afraid" of C, but there is no easy around the fact

that it will be needed soon. Most programmers do not share the enthusiasm

of writing in assembly language, present company NOT included in that statement.

[Mercury Thirteen]

Sure, you can make that combination call a specific routine and ctrl-alt-del call another. Those routines don't need to do anything just yet, though.

[Mercury Thirteen]

On Thursday, August 6, 2015 at 9:28:03 AM UTC-4, Antony wrote:

Next should probably be the file system or the virtual memory manager.

I'm working on some miscellaneous system probing code now along with direct disk access. After that's done, I can build FAT16 access on top. The memory manager will be next after the filesystem. After that's done... we party, because that's a significant milestone!

 

At some point, NightDOS will need a C compiler and C runtime. I know some of us are "afraid" of C, but there is no easy around the fact that it will be needed soon. Most programmers do not share the enthusiasm of writing in assembly language, present company NOT included in that statement.

Certain features would be much easier to implement in C, and we'll need it for application development in the end anyway. Someone needs to figure out how to successfully merge both languages, though. I'm okay with both C and assembly on their own, but combining the two and getting them to link nicely... not so much. I lost a whole day of development time on the issue and got nowhere.

Someone with more experience on that can probably make it work. I think you're the only professional developer among us, Antony, so you'll likely have better luck than I.

[Antony]

Check out the OS Dev wiki and also brokenthorn.com for some tips. Using GCC, we need to build a compiler. I'm working on that in Cygwin on Windows 8.1 (32-bit).

[Mercury Thirteen]

Maarten, since the mouse is tied into the keyboard data port, do you want to handle that as well?

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 3:09 AM, Maarten wrote:

Yes,  of course I want that! :)

Good deal. :) How's the keyboard code coming?

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 9:06 AM, Jatden wrote:

Should we add a login system,similar to that of windows?If so,I can program the login interface.

We may have that in the end, but that wouldn't be in the realm of kernel programming. As soon as I complete the sector reading code, can you work on the FAT code instead?

[Antony]

As NightDOS is equally open source as FreeDOS, we can probably (and should probably) leverage the FAT code from FreeDOS and just tweak it for the development tool (GCC).

No need to unnecessarily re-invent the wheel.

[Mercury Thirteen]

Good idea!

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 4:25 PM, Maartin wrote:

Slow :)

I don't have much time....
But tomorrow I can use the whole day to do make it...

Maarten

No problem, I'm still nowhere near 100% on DDA either, so we're even lol

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 4:32 PM, Maartin wrote:

Well, It's a good idea but with the blue box from fdbasecd.iso (new boot entry from Xfdisk) I don't like it.

For if you don't know where I'm talking about. See below (citation message)

Maarten

P.s. if no one knows what I mean with blue box.... just tell me I have an image from it but on my pc (I'm now on mobile).

You don't like what? A login feature or FAT access code?

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 4:49 PM, Maarten wrote:

Well not the one from FDBASECD.ISO.

But I don't know....
I like modern login screens.  But not "old" ones.  Also I like it fullscreen.  I know very specific :D

But we can do the user's choice right?
Or The Most Agrees (or dont agrees) win.

Maarten

We don't have to worry about a login screen at all. That's up to the shell program (and user) to decide. All we're doing in the kernel is providing the underpinnings upon which applications may run.

Speaking of underpinnings, I have to say this kernel has been a very freeing experience. There's no jumping through hoops, no adhering to a set of three decade old standards... just the pure simplicity of making whatever we want happen.

This is pretty fun :)

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 5:02 PM, Maarten wrote:

Also (Jayden?  If I spell your name right else sorry) if you have a design in mind could you in a way (drawing software, picture of a drawing etc.) Show that? Then I have a "guideline" and I can see it then... maybe then I see what you mean.

And from FDBASECD.ISO was if you had a boot entry (it was a login screen after this you had to type the password)... It was blue with a thick blue line. I have an image.... I didn't like that.

I see what you mean, but like I said, that's out of the scope of what we're doing with the kernel. The user can use a boot manager or whatever as they see fit.

Since Night is a direct drop-in replacement for the existing FreeDOS kernel, and boot manager which works with it will work with ours too.

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 5:08 PM, Maarten wrote:

Oh,  you mean it like that.... well, wrong readed then :)

No problem! Better to have ideas that don't make it into the kernel than a kernel devoid of any ideas. :)

[Mercury Thirteen]

On Fri, Aug 7, 2015 at 5:56 PM, Jayden wrote:

*Whew*.That means I don't have to program in assembly.

Yes! Good news, eh? lol

[maarten]

i can't get how i pull things.... and with the docs i had download some but that doesn't work. and i find it to much time-spending to make a file and then copy/paste.... and if it all doesn't work i have to but.... can someone help me with this?

i'm not good with Github and the description of Antony doesn't help me right now with this....

Maarten

[maarten]

Or is this a stupid question? Y

[maarten]

And it is still a very slow process....

[maarten]

And I'm not very happy about that!

Last respond....

good evening (or what time it may be in your country(s) )

[Antony]

Hi,

Real busy weekend. Sorry about that. Here's the book on git online -> http://www.git-scm.com/book/en/v2

Did you install Git on your local computer or are you trying to work from the website?

[Mercury Thirteen]

Sorry, but I'm not the best one to ask about Git... did you ever get it figured out?

[Antony]

GitHub for Windows has been working fine for me. I think it's become automatic for me because I use it at work so much. 

I sent the link to the manual online, hopefully that will help everyone. No one should be working on master or QA without Mercury's approval so all code should be in the Development branch.

[Mercury Thirteen]

On Tuesday, August 11, 2015 at 11:20:12 AM UTC-4, Antony wrote:

GitHub for Windows has been working fine for me. I think it's become automatic for me because I use it at work so much. 

I sent the link to the manual online, hopefully that will help everyone. No one should be working on master or QA without Mercury's approval so all code should be in the Development branch.

Thanks for the manual links! :)

[maarten]

Thanks to my brain I need to respond to this (how old it might be). :/
Yes, This is figured out. It works now....

[Antony]

Hi,

Perhaps if we can get on a schedule, maybe we can screen share and I can show you. I know we are like 12+ hours apart.

-T

[Antony]

[Mercury Thirteen]

I know development has been slow here, and that's my fault. My apologies to everyone!

We've been going through a fiasco at work which all started in September of last year when a key long-time member of our team retired. She was replaced with someone thoroughly inadequate (against the advice of yours truly) and, after her probationary period, this replacement was let go. We took this occasion to finally bring in the person I recommended in the first place, who has had to not only get up to speed as one normally would in a complex position, but also undo three months of screw-ups from the failed hire. Needless to say, I caught a significant portion of the workload fallout from all of this (as did the others on the team) which has severely hampered my free time. I'm not making excuses here, just letting you all know where I'm at with things. As time goes on, things are slowly going back to how they were before, and therefore I should have more time in the coming months (I hope) to implement the memory manager of the Night DOS kernel. After that, we can add minimal filesystem support then try test-running a few basic DOS programs which don't make use of the DOS 0x21 calls.

At least that's the plan. lol

[Mercury Thirteen]

...aaaaaaaaaand speaking of filesystem support, can we decide upon a basic one to support natively in the kernel? I'm assuming this would be FAT12 or FAT16, but as always, it's open for discussion. The perfect candidate would be compact with little overhead, unencumbered by patent BS (I'm looking at you, exFAT) and fairly simple to put together in assembly. I know I said I want the filesystem to be installable in Night DOS - and I still do - but we will need one single filesystem to do basic loading in the beginning before we even get to load our installable filesystem drivers.

[Maarten]

I would go with the default one from FreeDOS bootloader. As we are a replacement of that kernel there.
So, that would be Fat16 OR Fat32?
That should be our way, the one FreeDOS uses as default.

[Mercury Thirteen]

That's a good thought. It uses FAT16, and that's not too hard to implement.

[Maarten]

I searched for comparison:

                  Fat12                               Fat16                               Fat32
----------------------------------------------------------------------------------------------------------------------------------------
used for:   | Floppies               |    small harddrives   |         Medium to big harddrives            |
----------------------------------------------------------------------------------------------------------------------------------------
Size for    |                             |                              |                                                         |
each        |                             |                              |                                                         |
entry:       | 12 bits                  |   16 bits                  |         28 bits                                     |
----------------------------------------------------------------------------------------------------------------------------------------
Max .       |                            |                               |                                                        |
volume     |                            |                               |                                                        |
size:        | 16 MB                 |  2GB                       |  2^41 (whatever that number may be)  |
====================================================================



What would be the choice?

[Antony]

Unfortunately, you'd have to support all three variants of FAT. If NightDOS is added to a bootable floppy, it will have fat12, some FreeDOS installs are pre-formatted fat32.

[Maarten]

And there is a second problem. FreeDOS uses 2 bootloaders. one for Fat32 (which is chosen in xfdisk, and is used many times) and one for Fat16.

We could get problems when we have someone who tries to copy the kernel to the Fat32 system, while we have Fat16 implemented.

[Maarten]

I was also writing such problem 15 minutes ago... but I was 10 minutes looking for the good translation for a word.. :)

[Maarten]

But if we are busy anyway, we can do exFAT too, as some want that. But then I am maybe to enthousiast...

[Mercury Thirteen]

On Saturday, March 19, 2016 at 10:27:29 AM UTC-4, Antony wrote:

Unfortunately, you'd have to support all three variants of FAT. If NightDOS is added to a bootable floppy, it will have fat12, some FreeDOS installs are pre-formatted fat32.

 

Okay, sounds like all FATs it is. On the bright side, we'll need those in place anyway to serve as the int 21 handlers for file access, so... win win.

[Mercury Thirteen]

On Saturday, March 19, 2016 at 10:39:27 AM UTC-4, Maarten wrote:

But if we are busy anyway, we can do exFAT too, as some want that. But then I am maybe to enthousiast...

Thanks to Microsoft, we won't be implementing exFAT. They did their best to intentionally weight it down with such copyright crap that - to my knowledge - nobody is allowed to even make a reader for the format, let alone a fully functioning implementation.

Speaking of FAT implementations, would it behoove us to create a new updated FAT specification? Modern drives can reach into the 8 TB range, and FAT32 just won't cut that. I proposed a FAT64 spec in the FreeDOS forum which was quickly shot down, but I think it may still be useful for us. We could have a fairly modern filesystem which supports huge partition sizes, long file names (natively, not crammed in spare volume records as FAT32 does), enhanced attributes, maybe even alternate data streams, and all without having to build an NTFS driver.

[Maarten]

I think, that we need to hear arguments now. The FreeDOS list has it shot off, so there were one or multiple reason(s) for it.

What was said to be the arguments to Not use it?

What was said to be the arguments to use it?

Do they apply to our kernel (why yes and why no)?

Do we care about them? (probably not because it came to mind)

Do we really need it, or are there simpler ways to do it?

I am no OS developer stuff specialist. I learned about OS's in end 2014 I started to write them (from tutorials) in the beginning 2015's. I am here (the Night DOS group), to learn writing them. Also trying to understand them (what works now). I can't write one of my own, I actually always had some examples and tutorials with me so I can write a half working os. :\
That's why I am here, with my stupid questions, to learn. All those wiki's (I looked at) are about Assembly but after that they switch over to C and that's not what I want to learn and use, yet.

Anyways look at the first 7 sentences. And decide :)

[Maarten]

Also consider this,

We are meant to be a DOS in this case x86. Would someone that wants DOS have a 8 TB harddrive? I would think not. And remember, how are we going to install our kernel on a machine. If it's only copied so that it replaces the original (freedos) kernel.sys, then most people don't even dare to use their 8 TB harddrive only for DOS, if they do there could be two ways:

1. Smart, you use partitions. This means you have made a partition with max. 80GB

2. Stupid, you used your 8 TB harddrive to .... Off your computer. You don't need to be here.

That's really my opinion on this.

[Mercury Thirteen]

On Saturday, March 19, 2016 at 6:16:19 PM UTC-4, Maarten wrote:

I think, that we need to hear arguments now. The FreeDOS list has it shot off, so there were one or multiple reason(s) for it.

Actual arguments for and against weren't laid out, but nobody seemed too interested. Just kinda got no constructive feedback on it and the topic just sat there languishing - not to mention a swift smart aleck reply or two - so I took that as a no.

What was said to be the arguments to Not use it?

The bad:
-We would have to write up a new FAT spec, but this is not difficult.
-FAT isn't considered a truly "modern" filesystem since most of those use B-trees and journaling, but this will not. Why? Because I'm not well versed in these things, and I don't care to learn at this point. Extra features can always be added in later.
-It is - by design - not backwards compatible with other FAT versions. Making it so would defeat the very purpose of drafting FAT64 in the first place.
-No other OS could read it. Well, we could make a reader for other DOSes down the road, but initially Night DOS would be the only way to use a FAT64 volume.
 

What was said to be the arguments to use it?

The good:
-We can offer a fully-optimized, semi-modern, simple filesystem which is easy to implement with minimal overhead.
-It would support the current LBA-48 maximum disk size of 128 petabytes, and would already be set up for LBA-64 when it becomes widespread.
-Long filenames would be supported without having to "cram" them in unused structures, making them much more efficient and reliable.
-The concept of "clusters" becomes a thing of the past! :D


 

Do they apply to our kernel (why yes and why no)?

Not necessarily, because this functionality could be added later as a driver instead of embedding it into the kernel.

Do we care about them? (probably not because it came to mind)

We care because it affects our kernel for obvious reasons. :)

 

Do we really need it, or are there simpler ways to do it?

No, we don't absolutely need it, but I don't see a much simpler way to support huge drives under our kernel. Sure, there's NTFS, the whole EXT family, etc, but those are all have their own complex means of operation, whereas this would provide a simple way to do the same job without having to test the code we write to verify it behaves the exact same way as Linux or Windows in every circumstance. Besides, I think it would be a kinda cool addition to the feature set we offer.

...

[Antony]

Here are my questions:

1. Since this a new file system, not at all directly compatible with FAT32 and prior, why should it be called FAT64?

2. How would this affect the drop in nature of this kernel?

3. Would a new boot loader need to be written to parse the file system structures to find and load the kernel?

4. Would NightDOS prepare a boot partition with the kernel, load the file system drivers and then attach this new file system drive (similar to mounting in Linux)?

[Maarten]

Another question here, do we really need TB support? Like I said most DOS people don't use their 1 or 8 TB harddrive for DOS. They would do other things with it.

1. Use it as second harddrive, to store all your programs on.

2. use it as first harddrive, probably to use Windows or Linux.

Etc....

I don't want to destroy the idea, but we need to think about stuff like this.

[Mercury Thirteen]

On Sunday, March 20, 2016 at 3:19:36 AM UTC-4, Antony wrote:

Here are my questions:

1. Since this a new file system, not at all directly compatible with FAT32 and prior, why should it be called FAT64?

You know, I was considering giving it a unique (e.g. non-FAT) name. However, I think the name isn't inappropriate since its internal structures bear close resemblance to those of the FAT family and it still uses a traditional file allocation table.

 

2. How would this affect the drop in nature of this kernel?

It shouldn't affect it at all. We would support FAT 12/16/32 natively, then use the FAT64 driver later after boot time if needed.

3. Would a new boot loader need to be written to parse the file system structures to find and load the kernel?

No, we would pull a Windows maneuver and boot from a small FAT 12/16/32 partition, then use FAT64 for the rest of the drive.

 

4. Would NightDOS prepare a boot partition with the kernel, load the file system drivers and then attach this new file system drive (similar to mounting in Linux)?

 
A similar procedure would be followed, yes.

[Mercury Thirteen]

On Sunday, March 20, 2016 at 5:07:08 AM UTC-4, Maarten wrote:

Another question here, do we really need TB support? Like I said most DOS people don't use their 1 or 8 TB harddrive for DOS. They would do other things with it.

1. Use it as second harddrive, to store all your programs on.

2. use it as first harddrive, probably to use Windows or Linux.

Etc....

True, most people would not be using multi-terabyte drives. But for me this is one of those things where I think... if I can, then why not? If we're opening the door to PCI support and 32-bit multitasking, then why not huge drive support too?

 

I don't want to destroy the idea, but we need to think about stuff like this.

No, you're right. And that's exactly what this place is for!

[Maarten]

"You know, I was considering giving it a unique (e.g. non-FAT) name. However, I think the name isn't inappropriate since its internal structures bear close resemblance to those of the FAT family and it still uses a traditional file allocation table."

Who is the 'I'? Made it yourself?

[Mercury Thirteen]

On Monday, March 21, 2016 at 1:39:27 PM UTC-4, Maarten wrote:

"You know, I was considering giving it a unique (e.g. non-FAT) name. However, I think the name isn't inappropriate since its internal structures bear close resemblance to those of the FAT family and it still uses a traditional file allocation table."

Who is the 'I'? Made it yourself?

Yes, FAT64 is one of my designs. I haven't really even drawn up a formal spec yet, but I will need to do so.

[Maarten]

You cab search the web, thename is everywhere.

[Maarten]

Take a look:

https://www.google.nl/search?q=fat64&oq=fat64&gs_l=mobile-heirloom-serp.3..0i10j0l2j0i10l2.16777.19390.0.19810.7.5.0.2.2.0.617.1216.0j4j5-1.5.0....0...1c.1.34.mobile-heirloom-serp..0.7.1346.DsKLIcaAd7M

So, good work, maybe... I think? :)

[Mercury Thirteen]

I see. It looks to me like many people are calling exFAT "FAT64" since it apparently uses a 64-bit FAT as well. My FAT64 design (I claim zero responsibility for the kludge which is exFAT. lol) would support this as well as other features to modernize the FAT format into a simple open filesystem specification which this and other projects can use to support very large drive sizes.

[Maarten]

may I say something about the milestones? I just do,

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

 

First of all, can read/write sectors, it's not done, it's in progress actually, right?
Also, I find it realy unclear to look what we are doing. As you (or me) can edit the post, I would propose the following to make it clear:

- make things which are done green
- make things we are working on blue
- make things we couldn't complete red
- make things for the future and we are going to work on later grey

I like to have structure, which is pretty normal for autism... so YAY!
Anyway would that be accpetable?

Maarten

made possible by [:P]:
Knaagje, Eddy, Laurens and Simon (4 of the 8 pets in home. Knaagje (2) and Eddy (2) are my cockatiels, Laurens (12) and Simon (3) are the cats. only the animals I have something to do with are here :D )

[Antony]

Where I work, we have the concept of iterations. It falls under the concept of agile development. Each member on the team is assigned a task, and it has a series of subtasks, so for example:

Kernel interface to essential (keyboard, mouse, display) hardware (in progress) (core drivers)

The story would be along the lines of:

The kernel will have completed interfaces for core system functions

Acceptance criteria: (just off the top of my head)

1. All code should adhere to <whatever> standard

2. Unit tests assure that each component of the kernel is functioning properly

3. A standard calling API will be implemented that facilitates (provides) easier development

Then the development goes through the following steps

* Design Review and confirm Acceptance Critera

* Technical Design

* Programming

* Code Review

* Test Design Meeting

* Testing by QA

* Notification of Release

If each task is done in a similar fashion, we (as a team) will know where everything is. Those who are better at coding can handle the code. They can be assigned to engineer tasks.

Someone who is better at management can be the project manager. They can work with Mercury to flush out the tasks, acceptance criteria and such and build them out. Then as engineers are available, they can grab the tasks and work through them.

Unfortunately, since we're not a formalized company, the odds of using Team Foundation Services from Microsoft is pretty much not going to happen. So the first task from a team perspective to help with what you want Maarten is to find something similar for free and a place to host it if necessary.

If not, this can all be done in a spreadsheet on the Google Docs platform and shared with members of the team.

It sounds complicated, but this level of organization is needed to move the project along, otherwise everyone is jumping in writing whatever they feel. We'll end up with 3 takes on how to access hardware when only one is needed because 3 programmers took it upon themselves to take that task.

I can elaborate more, but I think I've belabored this too long.

Back to Java coding, today.

[Mercury Thirteen]

Sure, sounds good to me. Feel free to modify the colors as you have said.

So far as sector reading and writing, I think that's completed in that I have code snippets of assembly which do the job, but I have yet to integrate them into the kernel codebase.

[Mercury Thirteen]

On Tuesday, March 22, 2016 at 2:14:20 PM UTC-4, Antony wrote:

Where I work, we have the concept of iterations. It falls under the concept of agile development. Each member on the team is assigned a task, and it has a series of subtasks, so for example:

...

Back to Java coding, today.

I agree, a centralized place to keep track of our progress would be great. I'll have to look into the possibility of integrating Google Docs into our group.

I'm all for a more structured approach as long as we don't get caught up in the details and end up spending more time on the structure than the development! lol After all, we're only a handful of people so it's not like we have to use enterprise level solutions. In a setting like Microsoft, where you have thousands of programmers, then definitely yes, but I think for us your suggestion of Google Docs will be just fine.

[Maarten]

https://support.google.com/a/answer/167101?hl=nl

this is nl, so once you have the link make it "hl=en"

[Maarten]

You can look at the milestones, there is not yet something we couldn't complete. So green, blue and grey are used. Red will be used when we can't complete something.

[Maarten]

I tested the kernel files lately, which do work. But QA is far more behind than development. And as QA should happen regularly I would think updating it a bit? Quality approvement shouldn't be with complete different files, right? :)

[Antony]

Hi,

We probably need to sit down and design unit tests to test the code. It will make it easier for whomever is doing QA to test the code that is written. Unit testing doesn't exist for assembly language and since the consensus is not to use C, and short of implementing a C interface, we will have to find a means to test these system calls. Obviously, the running kernel doesn't have the ability to spawn applications at the moment, so perhaps a DOS application that runs in real mode (no XMS/EMS) that calls the kernel and allows interaction with the interfaces seems to be the only means to test in my opinion.

Once the kernel can read from the file system, we can write unit test applications to verify functionality.

[Maarten]

well, we did, still do, test with FreeDOS. We used the whole system and copy the NightDOS kernel to C: replacing the original Kernel.sys. But this is still very unpractical and I agree we need something else.

[Maarten]

I and mercury do QA. I just do QA bacause it's fun to do, but I take it seriously.

[Antony]

Hi,

Another thing, regarding website development for NightDOS, look at the site for Atom (http://blog.atom.io/) this is hosted via the github pages (https://pages.github.com/) feature which can be used to supplement this group with official documentation, a blog, task tracking, basically things to communicate to potential users and developers.

[Antony]

Hi,

I think we just need to spend a little time just to work out where things are heading, who's doing what? ETAs so we can stay on the same page. I'm not suggesting any type of paralysis on this, but it will help you out as well because you'll know (as the leader) where everything is and where resources should be allocated.

[Maarten]

Yes, well...

I am learning assembly, this is my third language. And I hope I can learn this one fully. But because of that, I am not good at programming yet. So I already do QA and I am searching a lot for you guys.... so?? :)

[Maarten]

So if we make those desicions, I think you all can better decide what I do.

[Maarten]

Okay, I think  we need to know the following:

- Are we all on the same page
- Do we need any new stuff or resources (Think of website stuff, developing stuff, etc.)
- Do we need to update the repo, are all branches up-to-date with what we are doing.
- What's the status of stuff, and are the milestones complete and still up-to-date
- Who is doing memory managment, paging
- Who is doing the keyboard now?
- Who is who:  what are our tasks in big lines

[Maarten]

And can I get approvement: am I allowed to update all README.txt files including on master? Some things I want to add, get rid off or make better.
Actually, I think the whole readme can be done better... The overall content will be the same.

[Mercury Thirteen]

On Wednesday, March 23, 2016 at 5:36:10 AM UTC-4, Maarten wrote:

You can look at the milestones, there is not yet something we couldn't complete. So green, blue and grey are used. Red will be used when we can't complete something.

Looks good to me!

[Mercury Thirteen]

On Wednesday, March 23, 2016 at 10:41:21 AM UTC-4, Maarten wrote:

I tested the kernel files lately, which do work. But QA is far more behind than development. And as QA should happen regularly I would think updating it a bit? Quality approvement shouldn't be with complete different files, right? :)

I have no problem with you doing QA, it's just that at this point there's not a whole lot to QA yet. The one exception to this is if you have access to a variety of hardware... now that could prove very useful.

[Mercury Thirteen]

Now that sounds like a good idea. We can make one .com program which will start off with the basics, then add more to it as the kernel matures. At first only have a couple of basics, maybe simple text printing to the screen. Then we can add disk sector loading, etc. Now the only question is... who's going to make that? lol

Any volunteers?

[Mercury Thirteen]

On Wednesday, March 23, 2016 at 11:03:45 AM UTC-4, Antony wrote:

Hi,

Another thing, regarding website development for NightDOS, look at the site for Atom (http://blog.atom.io/) this is hosted via the github pages (https://pages.github.com/) feature which can be used to supplement this group with official documentation, a blog, task tracking, basically things to communicate to potential users and developers.

Not a bad looking site. I already have a website I pay for, though, which we can use to host a Night DOS site. I just need to get it made and fit in with my existing content. Not that there's that much useful there anyway. lol

[Mercury Thirteen]

On Wednesday, March 23, 2016 at 11:08:41 AM UTC-4, Antony wrote:

Hi,

I think we just need to spend a little time just to work out where things are heading, who's doing what? ETAs so we can stay on the same page. I'm not suggesting any type of paralysis on this, but it will help you out as well because you'll know (as the leader) where everything is and where resources should be allocated.

I agree. A little added structure to our current approach wouldn't hurt.

[Mercury Thirteen]

On Wednesday, March 23, 2016 at 2:14:52 PM UTC-4, Maarten wrote:

Okay, I think  we need to know the following:

- Are we all on the same page

Maybe... we need to determine that. I think we can use the first post of the milestones thread for tracking this. That will keep it handy right here. Which means I need to sticky that thread.

- Do we need any new stuff or resources (Think of website stuff, developing stuff, etc.)

At this point, I really don't think so. We just need to get a little info together and better coordinate our efforts with the resources we already have available.

- Do we need to update the repo, are all branches up-to-date with what we are doing.

Nope, no major changes have been made to the codebase lately o everything should still be up to date.

 

- What's the status of stuff,

See the milestones section.

 

and are the milestones complete and still up-to-date

Yes.

- Who is doing memory managment, paging

I am.

 

- Who is doing the keyboard now?

Also me lol

- Who is who:  what are our tasks in big lines

 I think the readme answers that best.

[Mercury Thirteen]

On Wednesday, March 23, 2016 at 2:19:14 PM UTC-4, Maarten wrote:

And can I get approvement: am I allowed to update all README.txt files including on master? Some things I want to add, get rid off or make better.
Actually, I think the whole readme can be done better... The overall content will be the same.

Sure, I'm good with that.

[Mercury Thirteen]

Another thought: video handling. For our purposes I propose we adopt a more Mac-like technique, despite the PC and Mac traditionally having very different methods of handling video. Case in point: when manipulating pixmaps, color triple 0x00, 0x00, 0x00 means black on the PC, as in "all color beams off". The same color data will render as white on a Mac, as in "zero color data, just a blank white page here". Another detail: on the PC, if you're writing a game or what-have-you, you get to decide the resolution in which the application runs. Not so on the Mac, where your app must query the environment in which it's running, then adapt appropriately.

I side with the Mac method for a couple basic reasons:

1. I think we've all seen Windows games shift the resolution upon launching, producing a jarring "scramble" effect while the video card resets itself to perform video to the programmer's specifications. This not only looks ugly, but actually frightens some users who are convinced their video card just experienced some long term physical duress from the blast of random shapes and colors which occurs. Yes, there are more relaxed ways to do it, but why patch the issue when we can take a different road altogether? :) Now, granted "user experience" isn't something commonly associated with kernel design, but I think it's important to make our users as relaxed and at home using our software as possible. Subjecting them to ugly screen resets does not facilitate that in my mind.

2. Since we're going to be in protected mode - and we're not suicidal enough to rewrite the VESA routines manually - it would work better for us from a coding standpoint if we automatically detected the best screen mode at boot time, shifted to it, then locked it in place never to be changed by programs - the kernel will manage the main video buffer and its associated memory. This won't affect old DOS programs, since the kernel will have it's own default font and resolution/color handling tricks to make apps think they're running in the mode they picked when they're really not.

Note I am not proposing we handle color data like the Mac. Black will still be black under Night, only the video mode switching will be eliminated.

What are everyone else's thoughts?

[Maarten]

Would virtualbox and a laptop + pc enough? Yes I am not afraid to lose anything on those...

[Maarten]

Okay, I want to try, again to do the keyboard. I know we can't switch back and forth every time. But I want to try. The GDT was completed by me, with tutorials... So am I allowed?

[Mercury Thirteen]

VirtualBox, not so much. That's what I develop in, so I know the kernel will work there. I'm interested in running Night on a variety of real hardware so we can see how it does on actual metal in real world situations.

I will add that I'm not so interested in doing these real world tests just yet since the kernel at this point doesn't really do a whole lot. Once we hit milestone 1, though, this should be a definite objective. If anyone in the group has access to a wide variety of hardware, this may be something to keep in the mind for the future, should you want to volunteer that hardware for testing. :)

[Mercury Thirteen]

On Thursday, March 24, 2016 at 12:09:23 PM UTC-4, Maarten wrote:

Okay, I want to try, again to do the keyboard. I know we can't switch back and forth every time. But I want to try. The GDT was completed by me, with tutorials... So am I allowed?

Sure, I'm fine with that. You'll need to use the memory map in the repo to have your code write the keystrokes to the key buffer at the appropriate address.

[Maarten]

okay, need to say something. I had more on the documents then the tutorials. I almost never used a tutorial. Most of the things I had to do with the documents or out of my head. So that's good, I hope! :)

But.... unsupported interrupt ocurred and after that of course a guru meditation. so can you help me?

cmd:
; All these comments are things I know, and are not from any tutorials. just that you know I actually
; know something! -Maarten


push 0x07                    ; print the 'NightDOS:>' prompt
push 6
push 1
push kprompt
call PrintString

mov edi, inputbuff            ; point destination of stream operations to inputbuff    
   
mov al, 0                  ; clear input buffer
mov ecx, 256              
rep stosb  

mov eax, inputbuff
mov edi, inputbuff

.loop:
call keyboard

cmp al, 13                    
je .done


cmp al, 8
je .backspace

jmp .char

mov esi, inputbuff
call PrintString

mov esi, knocom
call PrintString

jmp cmd


.backspace:
mov ah, 0Eh
mov al, 8
int 29h
mov al, 32
int 29h
mov al, 8
int 29h
dec edi
jmp .loop




.char:
push eax
mov ah, 0Eh
int 29h
stosb
jmp .loop

.done:
mov ax, 0
stosb

mov esi, inputbuff
cmp BYTE [esi], 0
je cmd

mov edi, uhelpstrlc
call PrintString
call compare
jc help

compare:
pusha

.loop:
mov al, [esi]
mov ah, [edi]

cmp al, ah
jne .notsame

cmp al, 0
je .same

inc esi
inc edi

jmp .loop

.notsame:
popa
clc
ret

.same:
popa
stc
ret

help:
mov edi, khelpstr
call PrintString
jmp cmd


keyboard:
pusha
mov eax, 0
mov ah, 29h
int 21h
mov  [.buff], eax
popa
mov eax, [.buff]
ret

.buff dw 0         ;temporary variables can't be defined at the end of the file.


;until here are Maarten's comments, as is the end of the cmd stuff

[Maarten]

And remember, I am still learning.....

[Maarten]

last thing....

I think it has to do with the 0Eh, but I don't know how it should be replaced