INT 8h help...

[Kenneth Garin]

I now have a working real-mode stack switching multitasking include file for my OS but the problem is the timing of the scheduler. I simply hook INT 0x8 and once called it will save the state of the old task, resume the state of the new task and jump but the problem is not this, it's how everything is timed. Processes are getting too big of time slices from the timer interrupt so how can I set the timer so that it ticks faster? If I remember right it's normally set to 18.2x a second right? So how can I set it to lets say 6.5 or something? Thanks for ideas or help, Kg.

[crazybuddha]

Reprogram the timer. Here is an example of setting it to 18.2, but you can use this as a reference for different periods.

mov al, 0x36
out 0x43, al   ; control register -> channel 0, sq mode, r/w both hi/low
mov ax, 0x0000      ; low byte 1193182 / 18.2065 = 65536 is 0000 in 16 bits
out 0x40, ax   


This is going to give you trouble for any BIOS routines that rely on the timer (such as file transfers). In your ISR, you can keep track of whether 18.2 (55 ms, ) has arrived or not, then call the original BIOS handler.

I hope this makes some sense.    

[Kenneth Garin]

Is there a simple way around this? Im sure Os's have been programmed in real-mode using preemtive multitasking, how do they get around this problem?
Thanks though, Kg.

[crazybuddha]

I don't think so. The default setting of the timer is really slow. If you want finer-grained interrupts, you have to reprogram it.

You dont' have to mess with passing the interrupt on to the BIOS at first, This will simplify your job.

And it really doesn't get any simpler than four lines of code. Of course, reading about how the timer works can be a little time consuming.

[Schol-R-LEA]

Is there a simple way around this? Im sure Os's have been programmed in real-mode using preemtive multitasking, how do they get around this problem?
Thanks though, Kg.

By avoiding the BIOS routines in question, presumably. Many real-mode OSes have their own low-level drivers for certain subsystems anyway, as some BIOS routines (the disk access routines especially, IIRC) are problematic in a multitasking environment, because they busy-wait on the hardware rather than returning to the system while the operation proceeds. At least this has always been my understanding.