Ok,

I am currently working on writing an OS, this is mainly just for a bit of fun, and among the mainy roadblocks i have come across, this one is the biggest.

The problem is that now i have loaded my "kernel" and moved to pmode, i have no way of directly accessing the hardware...so i need to learn how to access certain devices, naimly, to start with, the floppy drive.

I have already learnt how to get keyboard input (though the characters dont resemble ASCII codes), and have discovered through investigation, that the port address for the first floppy on the system is 0x3f0-0x3f7.

The examples i have found have not been very uesfull, however i have found one that looks promising:
mov al,1
mov dx,3f2h
out dx,al

mov al,1
mov dx,3f3h
out dx,al

mov al,0
mov dx,3f4h
out dx,al

mov al,0
mov dx,3f5h
out dx,al

mov al,0a0h
mov dx,3f6h
out dx,al

mov al,20h
mov dx,3f7h
out dx,al


DiskBusy:
in al,dx
test al,8
jz DiskBusy
;this code is here to check if the program gets to this point...it doesnt
push edi
mov edi,0xb8000
mov al,"a"
mov ah,9
mov [edi],ax
pop edi

mov ecx,256
mov dx,3f0h
mov di,buffer
rep insw

I understand what the code does, or at least what it is supposed to do, but i cant get it to work, from the label name (DiskBusy), i assume that the fact it doesnt make it past this point is because the drive is busy, i also assume that the way to get around this is to reset the drive, but i cant find any examples of how to do that.

I have checked out ralf browns interupt list, and it has provided a little help, but not a lot.

Any help that anyone here can offer would be appreciated

Thanks

Take a look at this tutorial

That should be all the info you need

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

ok i am totally pissed off now

I have been using VMWare virtual machine to test my OS on and, have just found out that they dont apear to support direct hardware IO, (i gather this from the "NOT_IMPLEMENTED" error i get when i try), so i try to boot from my pc...and i get......wait for it...F**k all :@ i have no idea why. no error messages, nothing. do you have any way of testing this on something different to vmware, bochs for example (i couldnt get bochs to recognise the disk when i tried

any help would really be appreciated as i dont like the idea that i wasted my time

thanks

: ok i am totally pissed off now
:
: I have been using VMWare virtual machine to test my OS on and, have
: just found out that they dont apear to support direct hardware IO,
: (i gather this from the "NOT_IMPLEMENTED" error i get when i try),
: so i try to boot from my pc...and i get......wait for it...F**k all
: :@ i have no idea why. no error messages, nothing. do you have any
: way of testing this on something different to vmware, bochs for
: example (i couldnt get bochs to recognise the disk when i tried
:
: any help would really be appreciated as i dont like the idea that i
: wasted my time
:
: thanks
:
I never used VMWare so I dont know much about it.

Under Bochs, you can use this config file (I use it in my OS series)

# ROM and VGA BIOS images ---------------------------------------------

romimage:    file=BIOS-bochs-latest, address=0xf0000 
vgaromimage: VGABIOS-lgpl-latest 


# boot from floppy using our disk image -------------------------------

#floppya: 1_44=Floppy.img, status=inserted 

floppya: 1_44=a:, status=inserted

# logging and reporting -----------------------------------------------

log:         MicroOS_e.log
error:       action=report 
info:        action=report

This will make Bochs boot from either a virtual drive A:\ or a real
floppy disk.

You will not get any special error messages when you boot from floppy
on a real machine until you impliment it

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

awsome thanks mate, it works under bochs too...but not under real.

Do you have any suggestions, i thought that perhaps it might be the jump into pmode?

any ideas would be appreciated

thanks

: awsome thanks mate, it works under bochs too...but not under real.
:
: Do you have any suggestions, i thought that perhaps it might be the
: jump into pmode?
:
: any ideas would be appreciated
:
: thanks
:
it could be. Its impossible to tell without seeing that code

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

aha fair point...

well i shall tell you the latest "funs"...

got bochs working, thanks for that, and it runs my code...and it seems to support the out function...but when it gets to my code...(i have STUPIDLY deleted the bit that loaded from the disk..or didnt load as it happens)...it looks like it restarts, the screen resets itself to the start message, the floppy makes loads of noise and then it freazes..

I have encluded the source code

ok this is probably a stupid question, but,

how do you make the computer display the first section of video memory...the first "page" (2000 chars) if you will, i only ask because, i decided to test the code, and it would apear that it is accessing the video memory that is the problem, as even before any code has been executed (apart from setting the segments) i cant get a char displayed on screen using direct video access and the only thing i can think of is that i am displaying a char farther up the screen....above what i can see.....that looks like a really stupid thing to say, not sure how else to word it though...

ok...i have found that one of the problems is in the section that loads the OS, it appears that despite the fact that both bochs and VMWare run the code fine, my actual PC wont, it doesnt return any of the correct values.

: ok...i have found that one of the problems is in the section that
: loads the OS, it appears that despite the fact that both bochs and
: VMWare run the code fine, my actual PC wont, it doesnt return any of
: the correct values.
:
Alot of times there where be problems between real PCs and emulators.
The reason being is that emulaters are more perfect then real hardware.

ie, Bochs will clear most memory for you, a real PC will not.

Reguarding the first section of video memory...

The video card always displays the memory that was mapped for it.
This is done (Along with port mapping) in Real Mod by the BIOS.

You dont need to remap the display--just write to datasel:0xB8000.
datasel is the data descriptor base address (Useually 0x10).

Remember that pmode doesnt use the segment:offset memory model. ie,
its: datasel:absAddr. 0xB800:0 (Real Mode) is 0xB8000. So, assuming
datasel is 0x10, <b>0x10:0xB8000 is beginning of text memory</b>

What exactally is the problem (Descrete detail, please)?

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

:D i am so happy, i have finally managed to make the code work :)

OK here was the problem (full source clode attached):

mov al,[cs:TotalFATs]
mov cl,[cs:SectorsPerFAT]
mul cl
add al, [cs:ReservedSectors]
mov [DIRTable],al
mov al,[cs:MaxRootEntries]
mov cl,32
mul cl
mov cx,[cs:BytesPerSector]
div cx
mov [DIRTableLen],al
add al,[DIRTable]
mov [dataStart],al
mov cl,[DIRTable]
mov bx,0x200
mov ah,2
mov al,1 ;THIS LINE WAS "mov al,[DIRTableLen]"...so mov al,14
call get_location
int 0x13

reading 14 sectors at 0x200 wrote to 0x1000....writing null bytes...but for some reason loading the actual OS there did not overwrite these bytes, even though the .loadDIR code was called first (and not again), so the OS code should have been written on top, do you have any idea why it wasnt (the code now works on a real pc btw...although the kernel still needs lots of work.)

that is what i need to try to understand now, why did the OS not simply overwright the code....is it something to do with the memory being set to read not overright perhaps?

any suggestions would be appreciated...u may also have noticed that i totally re-wrote the code from the original, this was to try and make it simpler... and to understand it more

: :D i am so happy, i have finally managed to make the code work :)
:
: OK here was the problem (full source clode attached):
:
: mov al,[cs:TotalFATs]
: mov cl,[cs:SectorsPerFAT]
: mul cl
: add al, [cs:ReservedSectors]
: mov [DIRTable],al
: mov al,[cs:MaxRootEntries]
: mov cl,32
: mul cl
: mov cx,[cs:BytesPerSector]
: div cx
: mov [DIRTableLen],al
: add al,[DIRTable]
: mov [dataStart],al
: mov cl,[DIRTable]
: mov bx,0x200
: mov ah,2
: mov al,1 ;THIS LINE WAS "mov al,[DIRTableLen]"...so mov al,14
: call get_location
: int 0x13
:
: reading 14 sectors at 0x200 wrote to 0x1000....writing null
: bytes...but for some reason loading the actual OS there did not
: overwrite these bytes, even though the .loadDIR code was called
: first (and not again), so the OS code should have been written on
: top, do you have any idea why it wasnt (the code now works on a real
: pc btw...although the kernel still needs lots of work.)
:
: that is what i need to try to understand now, why did the OS not
: simply overwright the code....is it something to do with the memory
: being set to read not overright perhaps?
:
: any suggestions would be appreciated...u may also have noticed that
: i totally re-wrote the code from the original, this was to try and
: make it simpler... and to understand it more
:

In real mode, there is no memory protection--so all memory is writable.
To answer your question of "why" will require debugging it

I am very glad to hear its working now!

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

I am managing to work on, i now have basic user input working with a few recognisable commands, but i am still unable to have any kind of disk access, i looked through the site u recomended, and whilst it had lots of information, i found it hard to make sence of any of it, it described in detail how to set up the DMA controllerbut not how to use it to read data, do you have any other ideas where to look, perhaps some existing source code that i can learn from, or do you have any experience yourself?

as always any help would be appreciated.

Thanks

Ah! I didnt noticed you replied to this thread

I got to go to work soon, so Ill see if I can help you when I get back.

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

I assume you want to create a floppy driver then?

Do you have a low level memory manager already set up?

Creating a floppy driver can be hard. The site I posted earlier
is a very good site that should help you alot. I dont know (nor ever
seen) any other site that explaines it that well.

I currently am not at that step yet in my series, hence dont have any
code to post Not yet, anyway.

OS Resource Center should help alot.

More specifically, the tutorials here

If I find anything better that is specific to FDCs, Ill post it.

I also personally recommend looking at the source of an existing OS.
ie, see how they implimented it.

If you have experience in C, Perhaps this will help

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

ok, firstly yes i do want to write a floppy driver,and no i dont have a memory access module. I have experience of C++, and i could prob use my knowledge of that, the last site you gave me looked very helpfull, although for the real low level stuff (drivers etc) i was hoping to do it all in assembly, mainly for speed, also i have no idea how to use a C file with an ASM file.

thanks for your help, i am checking out some of those sites atm

: ok, firstly yes i do want to write a floppy driver,and no i dont
: have a memory access module. I have experience of C++, and i could
: prob use my knowledge of that, the last site you gave me looked very
: helpfull, although for the real low level stuff (drivers etc) i was
: hoping to do it all in assembly, mainly for speed, also i have no
: idea how to use a C file with an ASM file.
:
: thanks for your help, i am checking out some of those sites atm
:

How will you load anything from the drive without a good memory manager?
It will be impossible for you to know if it will overwrite existing data,
or even your kernel or other drivers without it.

Because you have experience with C++, just convert it to asm. Its not hard.
The tutorial I posted uses low level C, which compilies directly into
assembly language.

Dont *use* the source file, *learn* from it, and write your own. In fact,
write a better one. Believe me--not doing this will really hurt you,
and will almost definately halt your project.

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

thats a fair point, i hadnt really thought of that.

just want to run an idea past you (for a memory manager) sort of want to check if this is the right idea:

have a table in memory that shows what sections of memory are in use (perhaps divide memory into 1MB blocks? and show what blocks are in use, much like the FAT table does on a floppy disk with clusters?

thanks for the help, the tutorial you sent looks really good, i am just having a little fun atm (getting disk info) i have worked out how to get floppy info, and i can get C and D disk info, but i cant yet get any inf on sata drives...looks like this is gonna be a long project..GOOD :D

thanks

For an OS project--yes, it is going to be a *Long* while.

Its good that you are getting the drive information to work
though

As for creating a memory manager, you can impliment a malloc()
and free() routines, along others.

The idea is to store "memory blocks". By allocating blocks,
you can use Dog Tags to track memory curruption, and bad pointers.

I personally only seen (and implimented) these in C though.
Nontheless, this should help somewhat:

Clicky

After implimenting a way to "Allocate" and "Deallocate" memory, you
can test pointer validity in the memory blocks to indicate if the block
is used or not.

If you store all allocated blocks in a linked-list type structure,
you can keep track of all memory in use very easily, without having a
large table. Its also better, because you dont need to check unallocated
memory blocks

I can probably post my memory manager, if you want. Its in C++, though,
and tracks allocations from malloc()/free()/new/delete.

---

[.:EvolutionEngine][.:MicroOS Operating System][Website]

that source code looks like it could really help, so just let me make sure i understand, in the kernel code i define an data structure of a memory block:

mem_block
{
address
used
size
next
}
and then have a large amount of memory reserved for the list (256*len of mem_block???)

and then when i am after a free section of memory i just loop through the reserved memory looking for one with a used of 0?

if that is correct then i think i understand, but the only thing i dont really understand is how i am supposed to know what program (prog/driver/file...etc) is using which section of memory, should i have a label in the mem_block structure that is set to the name of the file loaded, or do i set a variable to the position of the memory location within the linked list?

sorry to be asking so many (perhaps silly) questions, i just like to thoroughly understand things, i find it saves time.

thanks

OK, i am now really confused, i used two documents on the FDC and DMA, one that had very good information but very little examples, and the other that was entirely an example and no info, I used these to help write my own floppy controller...or at least i thought i had, it appears too "work" as there are no errors in any of the status registers, however when i try a read operation i cant figure out how to tell it where to put the data in memory, and when i try a write operation nothing happens, even though there are no errors in the status registers, i have included the entire source code for my project thus far and i would really appreciate it if you could have a look and point out any "obvious" mistakes that you can see