FDC
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:FDC
kinda surprising how many people add FDC to their OS on january 05 ...
http://www.mega-tokyo.com/forum/index.p ... eadid=7200
http://www.mega-tokyo.com/forum/index.p ... eadid=7161
http://www.mega-tokyo.com/forum/index.p ... eadid=7206
any of these help ?
Ever tried to check OSRC, Bona Fide or the OSFAQ ?
http://www.mega-tokyo.com/forum/index.p ... eadid=7200
http://www.mega-tokyo.com/forum/index.p ... eadid=7161
http://www.mega-tokyo.com/forum/index.p ... eadid=7206
any of these help ?
Ever tried to check OSRC, Bona Fide or the OSFAQ ?
Re:FDC
The PIT is pretty trivial thing. Basicly, you probably just want to throw it some initialization, with the most interesting part being your tick-rate, after which it'll send you interrupts every tick. Documentation for this can be found in a lot of places, although surprisingly not in our Wiki. Anyway, Google for 8253 (or 8254) should give you the technical data, and you probably want to do something like this:Vladaz wrote: I have GDT, IDT, ISRs, but i haven't got PIT timer and DMA. Where can I read about these two?
Code: Select all
void timer_init(void) {
// Initialize PIT for the timer.
// counter0, LSB then MSB, square wave and binary counter
outb_p(0x36, 0x43);
// base frequence is about 1.19318MHz.
// want 10ms = 100Hz -> 1.19318 MHz / 100 Hz = 113931.8 ~= 0x2ea3
outb_p(0xa3, 0x40);
outb_p(0x2e, 0x40);
// Initialize tick-time.
timer_tick = 0;
}
About DMA I unfortunately can't help, because I've yet to reach a point of writing a driver that would need it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:FDC
the DMA (8237 iirc -- check out OSRC for documents & datasheets) is a chip that can be programmed to transfer data from an I/O card to memory.
Basically, you program a channel of that chip with a memory range and a transfer direction (e.g. 512 bytes, IO->RAM, phys. address 0x008000). The IOcard can then assert a signal on the ISA bus to tell the DMA it is ready for word transfer. The DMA then takes over the bus and performs IO read / mem write (or mem read/io write) and updates internal registers.
Basically, you program a channel of that chip with a memory range and a transfer direction (e.g. 512 bytes, IO->RAM, phys. address 0x008000). The IOcard can then assert a signal on the ISA bus to tell the DMA it is ready for word transfer. The DMA then takes over the bus and performs IO read / mem write (or mem read/io write) and updates internal registers.
Re:FDC
I had a look on the internet about PIT, and i got idea, that it can be used as a clock(like i.e. now is 5 hours and 20 minutes) and as you said, i understood that it can be used to help for multi tasking.
Did I get it right?
And where that PIT timer code should be written? Maybe to IRQ0 ISR ?
Did I get it right?
And where that PIT timer code should be written? Maybe to IRQ0 ISR ?
Re:FDC
Yes, you can use the PIT as a clock, although you probably want to use a more reliable source once in a while to make sure you didn't miss interrupts and possibly adjust for any PIT inaccuracy.
Like said, if you setup the PIT once with a constant tick-rate, you don't have to do anything special with it after the initialization; it will fire an interrupt every time it's counter hits zero, and then start again.
In IRQ0 ISR you then need to put whatever internal timer-management code you might have. Basicly, what my timer ISR does is increase the ticktime by one (ticktime is my kernel's internal idea of time), check if any internal timers have expired (and possibly signal relevant threads), then substract one from the currently running thread's timeslice, and if timeslice hits zero or if a higher-priority thread was released because of an expired timer, then call scheduler for reschedule. Otherwise just return to interrupted (user?) code again.
(Uh, that sounds like awful lot of work, but my kernel design allows all that to be done pretty fast, so I figured it's OK to do it directly in the ISR.)
Like said, if you setup the PIT once with a constant tick-rate, you don't have to do anything special with it after the initialization; it will fire an interrupt every time it's counter hits zero, and then start again.
In IRQ0 ISR you then need to put whatever internal timer-management code you might have. Basicly, what my timer ISR does is increase the ticktime by one (ticktime is my kernel's internal idea of time), check if any internal timers have expired (and possibly signal relevant threads), then substract one from the currently running thread's timeslice, and if timeslice hits zero or if a higher-priority thread was released because of an expired timer, then call scheduler for reschedule. Otherwise just return to interrupted (user?) code again.
(Uh, that sounds like awful lot of work, but my kernel design allows all that to be done pretty fast, so I figured it's OK to do it directly in the ISR.)
Re:FDC
Well, you don't NEED to do any kinds of fancy timer management.
On the other hand, if you want any kind of sane multi-tasking, then you WILL need (somewhat) fancy timer management.
If I was you, I'd take a short break from coding at this point, and think of all the things you want to do, then break them up into smaller parts, and continue until you start seeing what you need. Once you have all the parts, you start seeing how they must fit together, and design something that satisfies all needs you have. It's then much easier to write code without having to write it again the next day.
I'd also read a little basic theory about doing things like scheduling, IO and memory management. Knowing what you are going to encounter will help you understand what you going to do.
But, my approach might be too "scientific"; I'm the kind of person who likes to have a clear idea of what I am building, and why. At least make small list of things you want your OS to do. That'll help you a lot, and if you post it here, it'll help us a lot too. (Maybe you already did?)
On the other hand, if you want any kind of sane multi-tasking, then you WILL need (somewhat) fancy timer management.
If I was you, I'd take a short break from coding at this point, and think of all the things you want to do, then break them up into smaller parts, and continue until you start seeing what you need. Once you have all the parts, you start seeing how they must fit together, and design something that satisfies all needs you have. It's then much easier to write code without having to write it again the next day.
I'd also read a little basic theory about doing things like scheduling, IO and memory management. Knowing what you are going to encounter will help you understand what you going to do.
But, my approach might be too "scientific"; I'm the kind of person who likes to have a clear idea of what I am building, and why. At least make small list of things you want your OS to do. That'll help you a lot, and if you post it here, it'll help us a lot too. (Maybe you already did?)
Re:FDC
I don't really know if I am right, but I think it is in my OS project's website - www.neosign.tk (about TODO list).
Ok, I will try first to make that timer
;D
Then I will go on DMA, then floppy driver and then FS support(I think i will choose FAT12 for my floppy disk).
Ok, I will try first to make that timer
;D
Then I will go on DMA, then floppy driver and then FS support(I think i will choose FAT12 for my floppy disk).
Re:FDC
Hi,
In the last 10 years or so I've watched hundreds of projects like yours - in general there's 2 likely outcomes. Unfortunately, the first (most likely) possibility is that you'll stumble around in the dark for between 6 months and 2 years, then give up.
The second possibility is that you'll stumble around in the dark for between 18 months and 3 years while accidentally acquiring the knowedge you should've started with. After this you'll throw everything you've worked on away, do a little more research and a proper design, and then start again from scratch.
The difference between the first and second possibilities is your own determination. There's nothing really wrong with either method (I was determined enough to end up with the second possibility myself).
The point of all this is that there is a third possibility - spend 6 to 18 months researching and designing first. I personally guarantee that (if done properly, and if you are determined enough) it'll save you years of wasted effort in the long run.
In an attempt to help people avoid the mistakes I made, I wrote a "What to do before you start coding" document: http://www.mega-tokyo.com/forum/attachm ... e-code.txt
If it's not too much trouble, would you mind reading through it and letting me know if it was useful, and how it can be improved?
Cheers,
Brendan
Is this what you meant:Vladaz wrote: I don't really know if I am right, but I think it is in my OS project's website - www.neosign.tk (about TODO list).
To me this says you've got no real idea what your OS will do, how it will operate or which features it will support.NeoSign Operating System was created on summer of 2004. I (Vladas Chockevicius aka Vladaz) was intrested in OS developing, so I started my project. I hope this OS will have good future. This OS was planed to be designed as a Graphical Console User Interface(GCUI), but in a time VESA support was disabled and was started programming on a simple console, so that would be easier to see bugs and to program other important things for this OS. It will be a UNIX-LIKE operating system and in future it will have Windows/DOS applications integrated emulation.
In the last 10 years or so I've watched hundreds of projects like yours - in general there's 2 likely outcomes. Unfortunately, the first (most likely) possibility is that you'll stumble around in the dark for between 6 months and 2 years, then give up.
The second possibility is that you'll stumble around in the dark for between 18 months and 3 years while accidentally acquiring the knowedge you should've started with. After this you'll throw everything you've worked on away, do a little more research and a proper design, and then start again from scratch.
The difference between the first and second possibilities is your own determination. There's nothing really wrong with either method (I was determined enough to end up with the second possibility myself).
The point of all this is that there is a third possibility - spend 6 to 18 months researching and designing first. I personally guarantee that (if done properly, and if you are determined enough) it'll save you years of wasted effort in the long run.
In an attempt to help people avoid the mistakes I made, I wrote a "What to do before you start coding" document: http://www.mega-tokyo.com/forum/attachm ... e-code.txt
If it's not too much trouble, would you mind reading through it and letting me know if it was useful, and how it can be improved?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.