Page 2 of 2

Re: a few question about reading from a floppy

Posted: Fri Jan 22, 2016 1:02 pm
by newbi
kiznit wrote:
newbi wrote:I'm sorry I'm insisting in sticking to real mode, not because im stubbern, but because im developing a os for a university project, and i would like my first OS not to be too complicated
Real mode isn't less complicated. It might save you having to write some drivers (or not), but otherwise there is nothing simpler about real mode. It is more complicated to manage memory than in protected mode.
its about the feeling, id rather use intterupts only like using functions on high level language at first before i write actuall drivers on my own.
thank you for the respnose btw

Re: a few question about reading from a floppy

Posted: Fri Jan 22, 2016 5:00 pm
by azblue
newbi wrote: yep, some of the code is dead, since im not jumping into it by intention, not a mistake, im leaving that part for later .
if i set all the parametres to 0 before 13h,it will not read anything since the kernel is written in the second sector of the floppy.
or am i wrong?
I didn't say set the parameters to 0, I said set the segments to 0.

Re: a few question about reading from a floppy

Posted: Fri Jan 22, 2016 5:09 pm
by azblue
newbi wrote: 2. i located 0x8000 the stack, if it stretches down wont it overwrite my boot sector at some point?
Some people like to set the stack to 0x7C00 for exactly that reason. (Though as Brenden said, it shouldn't grow all that much anyway).
newbi wrote: also can someone explains to me what is there in the end of the memory (vector etc...)
I already gave you a real mode memory map.

int 0x12 will give you kilobytes of continuous memory in ax; I believe it should stop short of the EBDA.

Re: a few question about reading from a floppy

Posted: Sat Jan 23, 2016 10:09 am
by newbi
azblue wrote:
newbi wrote: 2. i located 0x8000 the stack, if it stretches down wont it overwrite my boot sector at some point?
Some people like to set the stack to 0x7C00 for exactly that reason. (Though as Brenden said, it shouldn't grow all that much anyway).
newbi wrote: also can someone explains to me what is there in the end of the memory (vector etc...)
I already gave you a real mode memory map.

int 0x12 will give you kilobytes of continuous memory in ax; I believe it should stop short of the EBDA.
hey, thank you for answering, what would memory mapping allow me? i guess in a small os like my own, from the boot sector i surely wont get to the end of my memory ranged in real mode am i? so i can be calm about that, but i'm having a real problem here.
if i wrote by terminal into the first second and third sectors of the floppy, and i got in the file that is written to the third sector an error that times -3 cant be negative, im guessing it because i tried to write to a sector more then 512 bytes, what do i do then? my os is intended to work in such a way that every process the kernel calls into will be alocated 1 sector(512 bytes allowed), but what will i do if the process will use more? i mean theres a way to write 1 file of code into 2 sectors? and then my process wont have such a problem?

Re: a few question about reading from a floppy

Posted: Sat Jan 23, 2016 10:51 am
by shmx
newbi wrote: i guess in a small os like my own, from the boot sector i surely wont get to the end of my memory ranged in real mode am i?
Use unreal mode.
newbi wrote:if i wrote by terminal into the first second and third sectors of the floppy, and i got in the file that is written to the third sector an error that times -3 cant be negative, im guessing it because i tried to write to a sector more then 512 bytes, what do i do then?
Why do you need a floppy disk? Try to use a flash drive and int 13h ah=42h. It is easier.
newbi wrote:my os is intended to work in such a way that every process the kernel calls into will be alocated 1 sector(512 bytes allowed), but what will i do if the process will use more?
Make reading files from FAT. It is not difficult.

Re: a few question about reading from a floppy

Posted: Sun Jan 24, 2016 8:14 pm
by Schol-R-LEA
I am getting a distinct, familiar itchy feeling here, one that tells me you haven't read (or at least haven't understood) some of the relevant parts of the wiki. If so, I would strongly recommend (re-)reading certain parts, especially
Getting Started
How To Ask Questions
Required Knowledge
Beginner Mistakes (the "deadlines" section in particular, though it seems that someone removed the specific warning against trying to write an OS for a University project, for some reason)
What order should I make things in
Code Management
How kernel, compiler, and C library work together
FAQ
Real Mode, especially the section on memory addressing, and Segmentation
Memory Map, Detecting Memory and A20 Line
BIOS, and Boot Sequence
Interrupts
Bootloader and Rolling Your Own Bootloader
FAT and SFS

Whle this is a lot of reading, it simply reflects the due diligence that any OS-devver needs to go through in order to get anywhere. OS development, even as a simple project, is not amenable to the Stack Overflow cut-and-paste model of software development; you really need to understand a fair amount of the concepts and principles before writing any code, and the examples given in tutorials and forum posts generally are exactly that. Copying an existing code snippet without at least a basic idea of what it is doing simply won't do. While learning itself is an iterative process - you learn one thing, try it out, see what worked and what didn't, read some more, etc. - in this case a basic foundation is needed at the start. Without a solid understanding of at least some of the core ideas before starting, you simply can't get very far in OS dev.

As for us helping you, it might be useful if you could give us some idea of what your project goals and scope are. Given that you are starting with the boot loader (which we generally do not recommend - it is a lot of work for a very, very small and largely irrelevant part of the OS framework, and existing generic bootloaders like GRUB or Gujin can do a lot of things that would take you far too long to implement yourself), is the bootloader itself the primary goal, or a key part of the OS design in some way, or are you constrainted regarding it in some way (e.g., the code has to all be your own for the professor to accept it)? How do you intend to write the rest of the OS, and what type of OS design do you have in mind? How long is the deadline for the project? Knowing these things would make it a lot easier for us to help you.

Finally, as always, remember to put your code under source control if you haven't done so already. Seriously, do it. If you don't, you will come to regret it.