Jan Atle Ramsli <[EMAIL PROTECTED]> writes:

> #include <linux/sysdeps/io/weirdness/haltandcatchfire.h>
> main()
> {
>       shotime();      /* Oh yeah */
>       /* Kikk klokks bott */
>       outb(0x43, 0x34); /* The fact that 0x34=00110100B has some */
>                       /* significance (control word, I'll see if I can find it) */
>       outb(0x40, 0x00); /* The 00 part of 0x2000 */
>       outb(0x40, 0x20); /* The 20 part of 0x2000 - what it means? I'll see if .. */

Beware, <asm/io.h> on Linux defines outb(value, port).  Swap the
parameters if you use that.

> I wonder what they did to the Motorola chip? Are they compatible?
> Is the 8253 part of a 'chipset' now?

Both the RTC and the PIT exist in PCs nowadays; perhaps not the
original chips, but something compatible anyway.

If "sleep 10" sleeps for the wrong time, the problem might be in
the PIT which is usually used for scheduling.  But since the
original poster wrote about the "hardware clock", I suppose his
problem is in the RTC.

> Ah: Is this right? "Mode 2 is a 'Rate Generator' with periodic binary counting"
> What, then, is mode 3? And mode 1? Is there a mode 0?

According to HelpPC, there are 6 modes.  Mode 3 generates a
square wave; mode 2 gives only short pulses.  Modes 1 and 0 don't
reload the counter automatically.

> It will give 18.206 pulses/s, which seems reasonable for task switching

Linux reprograms the PIT to 100 Hz.  (On Alpha, it uses 1 kHz;
but I don't know if it's the same chip there.)

> This whole thing will generate INT 0x08 periodically - is this still valid when Hurd 
>runs (probably not?)

It is connected to IRQ0, which can be directed to various INT
numbers by reprogramming the interrupt controller.  On Linux,
IRQ0 goes to INT 0x20.

Reply via email to