OSDev.org

umm if you say the 'outw' function i've just deleted it, i didn't even knew that it was there

include/system/system.h
include/system/system.c

Also .c files should go in their own directory and not in the include folder

ok, i deleted it from github and from my code, now there should only be a 'inportb' and 'outportb' function

if i do instead of get first the param and then the ADDRESS_REG it even doesnt print when i try to convert it to decimal

You're also trying to feed an integer into the print char function you need an int to ascii(itoa) function. Strings are encoded in the ASCII format but integers are not.

so i should convert it to ascii values instead of an integer?

You should use an itoa function to fill in a buf with that number represented in ASCII to give to printf

I wasn't going to say this, because while this does go against convention, it really is just convention. Still, I agree that it would make sense to change it to fit that convention, both as a means of managing the files, and to avoid confusion.

I also was wondering why you included the binaries (the .o files and such) in the Git repo; usually, this would be excluded (using the .gitignore file to set which files not to add) because a) you usually only want to have the source files and documentation in the repo (and maybe some of the resource files such as images/tilesets/etc, though these would usually be in a separate repo if there a large number of them), to reduce disk and bandwidth usage, b) the object files corresponding to any touched source files (those which have edited since the most recent make) will be regenerated whenever the code is compiled, and c) distributing executable (or just linkable) binaries without a hash signature presents trust issues, even if you have no malicious intent.

I've tested the bcdtoint() function, and found that it does work correctly; however, for the sake of clarity (and some improvement in speed, at the potential cost of runtime stack use depending on compiler optimization), I am re-writing it with a bit more explanation, along with a corresponding Int to Packed BCD function. I'll post those in a little while, once I have finished testing my version of it.

EDIT: Here's the test code I mentioned. As I said, it doesn't look as if the BCD-to-integer conversion was to issue anyway, but I figured I would include it for the sake of completeness. Also, I deliberately spread the conversions out a bit to make them easier to read.

thanks for the code! in the repo are the .bin and .o files 'cause i want to have an apart dir to have the .o and bin files, and if you see a 'obin' directory you probably won't know what's the reason of it, so you can enter and see whats in

EDIT:
when i compile the code, ld gives: undefined reference to '__assert_fail'
it's a problem from the assert function, but the assert.h is included

Oh, I get that, I think, but my point is that while you might want a directory for them on the individual development hosts, you usually wouldn't want the Object Files themselves in the online hosted repo - they just take up space on the cloud host, and increase the download bandwidth for anyone else who is cloning or forking the repo.

Git itself has a way of handling this, with a hidden resource file called '.gitignore'. This lets you update the Git repo while omitting certain files or file types that are in the repo's directory structure, but which don't need to be bundled into the repo package itself (because they are redundant, are automatically generated by the build system, only apply to the local system, or anything else like that).

The official documentation for this is on the Git website. You might want to read this James Coyle tutorial which explains this in greater depth. Note that this is a function of Git, not of the GitHub host, so it would work for any other host using Git; other Source Control tools such as Subversion or Mercurial have their own ways of getting the same results.

I don't know how well you know Git and GitHub, so you might want to look at this tutorial if you don't know it all that well yet, as well as more of the Atlassian Git tutorial I've already linked to.

The practical upshot of this is that if you add a .gitignore file to the top directory of your Slidoor-OS repo, with the following directives, it should omit the object files, libraries (the *.a files, which are basically just a collection of several *.o files bundled together, the *.so are similar, but are used for share libraries, something your OS presumably doesn't support yet) as well as things like backup files and other non-essentials:



This will leave these files in your local host's file structure, but omit them from the uploaded files whenever you push to the cloud host. A more extensive 'default' .gitignore for C development in general can be found here, though you need to keep in mind that this is only an example file - you can, and probably should, modify it to suit your own needs.

I don't know if you have a specific need to include the /obin directory itself, or its contents, or the .iso file for the disk image, but if you don't, you can do this so that they don't take up space on the cloud-hosted repo.



On the one hand, I was using that to test the code; you should be able to remove the asserts without any problems.

OTOH, it would make sense to address the problem itself, which is that you don't have a library with the assert function in it. See the wiki page Creating a C Library for details about how to fix this.

Which brings up another issue with your header files: some of the functions are in the header files, including the bcdtoint() function. this is an extremely poor idea. The wiki has a page which explains the reasons for this in depth, but the important thing here is that (with the exceptions of inlined functions, macros, and in C++, templates) functions should be in a separate source file, which can be compiled to linkable object files, with only the function prototype in the header.

The Object Files are, of course, the compiled results of the individual compiled source; these are what the linker works on to build the final executable binary, and the object files are usually in a variant of the Executable Format used for that executable. But this is all 'you should know this already' stuff, so I don't want to insult your intelligence by belaboring it.

I will mention that you generally don't want to #include headers inside of other headers, and you should put header guards around the body of the header to prevent repeated inclusions (which can cause 'multiple definition' errors).

On a slightly related note: don't name the entry point to your kernel main(). the main() function has a very specific use in C, with a specific set of allowable function signatures, and using the name main() for anything else tends to break a lot of things. You probably want to use a name such as kmain() or something. I'm frankly surprised it compiled at all as it is - if you were using the recommended warnings, such -Wall and -Wextra, in your command line options (something I strongly recommend for any GCC builds), it would have flagged this.

I also recommend that instead of a hand-coded shell script, you use a build automation tool such as GNU Make, CMake, Ant, Ninja, Meson, or the like. Some are based on the classic Unix make(1) tool, while others might use XML files or some forms of GUI tooling; the point is that they do a lot of this work for you, which ever one you choose, and don't depend on their being a BASH shell to run the script in (meaning they are more usable under, say, Windows).

ok.. i'm already thinking that there's something wrong with the get_RTC_val() function and not with the conversion from bcd to int, now i got the image posted below(also i've updated the github repo, so you'll can see the code)

I'm going to make a serious recommendation. If you intend to use QEMU you should consider using remote symbolic debugging. When assembling with NASM use -g -F dwarf and with GCC use -g to enable debug information. Then spin up QEMU and GDB with something like:

The -rtc base is convenient if you are trying to set the day and time to a known value. I'm also using qemu-system-i386 rather than the 64-bit version to keep GDB and QEMU in sync with the type of code that is running.

I don't believe the standard puts any restrictions on main's prototype when compiling for a non-hosted environment using GCC's -ffreestanding option

OK, before I look at the problem, I think I may have misstated some of the stuff about the headers; you only needed to move the functions out of the header. The declarations for things like macros, typedefs, and shared constants should be in a header, as should be the function prototypes.

(Shared variables are a bit more complicated - those should have a declaration in the header file, and a definition in the source file, which looks like so:



And yes, that's almost, but not quite, the same, a fact which makes it easy to get turned around. The difference is that the declaration only says what the variable is, while the definition - like a function definition - allocates memory for the variable and does similar preparation for it.)

Also, note that the types defined in stdint.h are all postfixed with '_'t', just like the size_t type is. I know that you have your own 'types.h' header, but I would recommend replacing that with appropriate versions of the standard type headers (stdint.h, stdbool.h, stdfloat.h. etc.) for your compiler and OS. The OpenGroup website (which handles the POSIX standard for Unix-like systems) has documentation for all of the POSIX standard versions of the headers (which more or less match those for the C11 standard, though they also include several Unix-specific ones), so you may want to review those before implementing or porting any C headers and libraries.

So, for example, the assert.h file usually contains just a single macro definition, a simple if not especially complete version of which might be:


Stepping up a bit in complexity, a bcd.h header and library might be:


I've omitted the 'nybbles_to_bcd()' function, as that was simply part of my testing scaffolding, not something you are likely to ever need.

bcd.c


And yes, I am suggesting keeping these separate; while BCD doesn't come up often, it occurs often enough that a simple stand-alone library like this might be worth having on hand. Given this, this would give you a cmos.h like this:



I'll address the functions shortly; suffice it to say, I am pretty sure that the function signatures are going to change, so those prototypes will have to, too.

OK, fair point; I really don't know either way, as it has always been one of the "Here There Be Nasal Demons" parts of the standard. A lot of things are left to implementors once you are talking about code which is by definition non-portable.

I'd still recommend using a different function name, even if it is technically permissible.