OSDev.org

osdevnewbie wrote:

iansjack wrote:If your code is interesting enough that you ask others to spend their time helping you with it

I've sincerely apologized for wasting your precious time.
when I said "not interesting" I meant for other people, cause I'm following a guide posted on the web since a long time, so there's no NEW thing I've done.
For me of course it's very very interesting.

Be that as it may, the fact is that even with regular backups, version control is still very useful, and not at all difficult.

Besides, it is a good habit to get into for any programming project. It seems to me that this is exactly to time to get into that habit, while you are working on something where the consequences of a mistake aren't so dire, and you can freely experiment with a VCS to get the feel of it, and try out different VCS programs to see which ones you are comfortable with - there are about a half dozen VCS systems to choose from, each with their own strengths and weaknesses.

Note that most of these are primarily shell-based but some (mostly the commercial ones such as Perforce or Team Foundation Server) use GUIs as the standard interface. The command-line ones have add-on GUI or Web interfaces for them, such as Tortoise for SVN or the Git Windows Client. Also, most IDEs have a version control hook or add-on which can be used with at least one of the common VCSes, and most have add-ons for several; you usually can use either SVN or Git, at least, and most support both.

In case it isn't clear, Subversion and Git are far and away the most common ones, and Git especially is very popular right now thanks the relative ease of use on GitHub. While Git is somewhat contentious - a lot of people really dislike it - it is worth knowing even if you aren't using it yourself, because so many other people are using it and a lot of open-source software is hosted through GitHub.

I don't want to sound like a broken record, but there really are a lot good reasons to use a VCS, and most people, no good reason not to.

MichaelPetch wrote:if you want to reduce code since and get rid of the 4kb you can use this:

Code: Select all

ld -nostdlib -T NUL --file-alignment 0 --section-alignment 32 -o kernel.tmp -Ttext 0x1000 kernel_entry.o kernel.o

Yes this works great, thanks.

MichaelPetch wrote: The reason your code started to break when you moved the vidmem to global scope is that it was placed in the data section, and that would have added an additional 4kb to your kernel. Since you only load 15 sectors (of 512 bytes each) for the kernel that will exclude anything beyond from byte 7680 (15*512) onward. Your `vidmem` pointer likely fell outside the kernel you were loading and thus not initialized to 0xb8000 .

even with 30 or 40 sectors loaded and with the stripped version (ld -nostdlib -T NUL --file-alignment 0 --section-alignment 32) this still not working !!

MichaelPetch wrote: I noticed an issue in your Makefile. You have this:

Code: Select all

kernel.O: kernel.C

Case matters here I believe you want

Code: Select all

kernel.o: kernel.c

. The way you have it would produce kernel.o from kernel.c using the default Make rules.

I changed kernel.C to kernel.c with no effect !

osdevnewbie wrote:

MichaelPetch wrote: I noticed an issue in your Makefile. You have this:

Code: Select all

kernel.O: kernel.C

Case matters here I believe you want

Code: Select all

kernel.o: kernel.c

. The way you have it would produce kernel.o from kernel.c using the default Make rules.

I changed kernel.C to kernel.c with no effect !

Just figured I'd clarify why MichaelPetch suggested this (presumably). Unix filesystems are case-sensitive. In the really old days of C++, before it was even called C++, it was called CFront, and the compiler determined whether or not to pass the code through the cfront transpiler based on the file extension. Lowercase C meant a regular C source code, and uppercase C meant CFront (C++) source code. This ended up being a bad idea, because some filesystems like FAT12/16 stored filenames in all caps. Alternative file extensions included ".cc", ".cpp", and ".c++" for source code and ".H", ".hh", ".hpp", and ".h++" for headers.

osdevnewbie wrote:I changed kernel.C to kernel.c with no effect !

You did see that I asked you to also change kernel.O to kernel.o? And when you say it doesn't work - in what way?

Ok now I get the string printed when I declare a global pointer to video RAM.
Many thanks for all of you.
The next step will be using Interrupts, the timer or the keryboard.