DOS ain't dead

I'd like to install an ISR on the IRQ0 of the PIT timer. I don't want to use INT $31 to install it - my ISR has a very high priority and should run at a very high frequency and work on very low end PC's also - I want to register it in the IDT instead to avoid time waste in the DPMI host with all the routing/reflecting/chaining magic. What is the best way to do ? I don't really know what to write into the 8 bytes of IDT entry to call my ISR rather than rise a TripleFault And what IDT entry does it use at all ? 8 is a Double Fault I'd like to minimize the HW switching magic (stack / Ring / memory model (???) ) on my IRQ as well. It's irrelevant whether my ISR "lands" in Ring0 or Ring3, it doesn't need any "API", just a minimum of registers and stack space, and can (should ?) run with interrupts disabled. Also I'd like to prohibit (in the main "thread") all interrupts except my IRQ. Should I redirect all IDT entries to a dummy IRET or are there better ways to do?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> I'd like to install an ISR on the IRQ0 of the PIT timer. I don't want to
> use INT $31 to install it - my ISR has a very high priority and
> should run at a very high frequency and work on very low end
> PC's also - I want to register it in the IDT instead to avoid time waste in
> the DPMI host with all the routing/reflecting/chaining magic.

using the IDT directly instead of DPMI doesn't gain much. I tested DPMI IRQ 0 routing to ring 3 on a P4 1.6 GHz with increasing frequency (reprogramming the timer) and it worked up to 180 kHz. Of course it depends what exactly you want to do inside the ISR.

> What is the
> best way to do ? I don't really know what to write into the 8 bytes of IDT
> entry to call my ISR rather than rise a TripleFault And what IDT
> entry does it use at all ? 8 is a Double Fault

that's indeed a problem when you want to modify the IDT directly. You don't know which INT is indeed used, the DPMI host might have reprogrammed the PIC (WinXP, Win9X and Linux do at least). If the PIC is not reprogrammed, IRQ 0 and Exception 08 use the very same interrupt.

> Also I'd like to prohibit (in
> the main "thread") all interrupts except my IRQ. Should I redirect
> all IDT entries to a dummy IRET or are there better ways to do?

the simplest way is to mask out the other interrupts (OUT 21h, FEh).

---
MS-DOS forever!

Thank you

> using the IDT directly instead of DPMI doesn't gain much. I tested DPMI
> IRQ 0 routing to ring 3 on a P4 1.6 GHz

Well, my apps should work on "slightly" slower PC's also

> don't know which INT is indeed used, the DPMI host might have reprogrammed
> the PIC (WinXP

Have not yet seen a DOS app successfully using the PIT under NT/XP at all ... no timing beyond emulated "BIOS" 18.2 Hz clock

> If the PIC is not reprogrammed, IRQ 0 and Exception 08 use the very same interrupt.

Is this true under HDPMI32 ? Does HDPMI32 poll the PIT to distinguish them ?

> the simplest way is to mask out the other interrupts (OUT 21h, FEh)



And what should I write to the 8 bytes of the IDT entry 8 ? Can I pick them from there (same/different entry ?), hack the address, maybe change some of the Ring stuff (???) to get the most straightforward "asynchronous" subroutine call ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > If the PIC is not reprogrammed, IRQ 0 and Exception 08 use the very same
> interrupt.
>
> Is this true under HDPMI32 ? Does HDPMI32 poll the PIT to distinguish them
> ?

No. it uses the value of ESP to determine if it's an IRQ or an exception.

> And what should I write to the 8 bytes of the IDT entry 8 ? Can I pick
> them from there (same/different entry ?), hack the address, maybe change
> some of the Ring stuff (???) to get the most straightforward
> "asynchronous" subroutine call ?

I think this is an excellent exercise for learning low-level programming, so I don't want to spoil this pleasure by telling how it is done.

---
MS-DOS forever!

> tested DPMI IRQ 0 routing to ring 3 on a P4 1.6 GHz with increasing
> frequency (reprogramming the timer) and it worked up to 180 kHz.

Does it mean that main "thread" performance sank to almost 0 then ?

If YES, then the IRQ wastes 10'000 cycles per piece ... and it's desperately inefficient and unusable

> > Is this true under HDPMI32 ? Does HDPMI32 poll the PIT to distinguish
> them
> > ?
>
> No. it uses the value of ESP to determine if it's an IRQ or an exception.

YES. At least to my 1st question

My disassembled code seems lost

It just compares the ESP against a value stored in a magic place of the stack (or 1 of 4 stacks) ?

> I think this is an excellent exercise for learning low-level programming,
> so I don't want to spoil this pleasure by telling how it is done.

Thanks

Well, it seems to work now



; ************************
; *** !!! Hack IDT !!! ***
; ************************

; Ban interrupts

        CLI                       ; Ban all

        mov   al,$FE
        out   $21,al              ; Ban all except timer after STI

; Backup existing values

        mov  ebx,[edi+16]
        mov  eax,[ebx+$40]
        mov  [edi+16+4],eax
        mov  eax,[ebx+$44]
        mov  [edi+16+8],eax

; Prepare

        lea   edx,[ebp+sspalhack] ; Low 16 in DX
        mov   eax,edx
        shr   eax,16              ; High 16 in AX
        mov   cx,cs

;Write

        mov  ebx,[edi+16]
        mov  [ebx+$40],dx          ; Low 16
        mov  [ebx+$42],cx          ; CS
        mov  [ebx+$44], word $EE00 ; Junk 0 | Magic value $EE
        mov  [ebx+$46],ax          ; High 16

Using magic value $EE - same as HDPMI32 places there (to jump to Ring 0 and switch stack ?) and VESAMTRR (to shoot the great "protection" ) and my flat ZERO-based CS

Well, there results are much better than your 180 KHz on 1.6 GHz ... but pretty weird :

- Ring0 DexOS version is slower than Ring3 HDPMI32 version

- 1.7 GHz P4 is slower than 500 MHz P3 (seems to slow down extremely on OUT instruction )

EDIT by rr: Changed subject. Three "e"'s are enough!

> > tested DPMI IRQ 0 routing to ring 3 on a P4 1.6 GHz with increasing
> > frequency (reprogramming the timer) and it worked up to 180 kHz.
>
> Does it mean that main "thread" performance sank to almost 0 then ?
>
> If YES, then the IRQ wastes 10'000 cycles per piece ... and it's
> desperately inefficient and unusable

You are very rigid today.

---
MS-DOS forever!

> You are very rigid today.

NO

You missed the point - this was no offense at all

The target of my criticism "desperately slow and unusable" was "the idea of using INT $31 to install a high frequency ISR under DPMI, slow because of CPU and DPMI design" , and NOT your implementation of IRQ's in HDPMI32 The HDPMI implementation is very good (probably, no exact tests) ... and, BTW, my ISR works well under it (via IDT)

Please look at my yesterday's posts again

> You missed the point

> The target of my criticism "desperately slow and unusable" was "the idea
> of using INT $31 to install a high frequency ISR under DPMI, slow because
> of CPU and DPMI design"

No. You won't gain much by modifying IDT directly. The 180 kHz limit is mainly caused by a slow! write to the video memory inside the ISR. A real-mode version of the test program - where calling the ISR is done without overhead - also stopped at the very same frequency.

---
MS-DOS forever!

> No. You won't gain much by modifying IDT directly. The 180 kHz limit is
> mainly caused by a slow! write to the video memory inside the ISR. A
> real-mode version of the test program - where calling the ISR is done
> without overhead - also stopped at the very same frequency.

Thanks for this additional info ... since you hadn't mentioned the content of your test ISR I just had assumed it would be dummy ... and the 10'000 cycles wasted by the "overhead" only

But I have some doubt how reliable the test against RM is ... since 80486 CPU's are optimized for 32-bit PM performance and the 16-bit RM performance is known to be poor ... "minimal correctness" is considered as sufficient. Thus, the PM version could waste "much" time in the overhead, and the RM version the accidentally very same amount of time because of poor performance of "ordinary" instruction execution

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> But I have some doubt how reliable the test against RM is ... since 80486
> CPU's are optimized for 32-bit PM performance and the 16-bit RM
> performance is known to be poor ...

Really? I never heard that, only heard that PPro was bad at 16-bit stuff (vs. Pentium 1), eventually corrected in PII or whatever. Got any online references to point us to regarding that?

And BTW, my 486 Sx/25 is very slow at most things regardless, not exactly a speedy cpu (and yet supposedly twice as fast as an equivalent 386, sheesh). But anyways, such a machine could run King's Quest 6 flawlessly, one of my all-time favorites, a truly excellent game, so I can't hate it.

http://www.mobygames.com/game/kings-quest-vi-heir-today-gone-tomorrow/screenshots

---
Know your limits.h

> Really? I never heard that, only heard that PPro was bad at 16-bit stuff
> (vs. Pentium 1), eventually corrected in PII or whatever. Got any online
> references to point us to regarding that?

Since memory writes for 80386+ are always done in DWORD chunks, there's indeed a - small - benefit for 32-bit software using a properly aligned 32bit stack and DWORD variables. However, I doubt that this is significant for the case we are talking about in this thread.

---
MS-DOS forever!

> > Really? I never heard that, only heard that PPro was bad at 16-bit stuff
> > (vs. Pentium 1), eventually corrected in PII or whatever. Got any
> online
> > references to point us to regarding that?
>
> Since memory writes for 80386+ are always done in DWORD chunks, there's
> indeed a - small - benefit for 32-bit software using a properly aligned
> 32bit stack and DWORD variables. However, I doubt that this is significant
> for the case we are talking about in this thread.

I'm sure you're more knowledgable than me in pretty much every way, but I heard that a 386 Sx had a 16-bit external data bus vs. 386 DX and all 486s (even Sx) which have a 32-bit one. And the Pentium has a 64-bit one, last I heard. Plus, the original IBM PC was an 8088 and had an 8-bit one (vs. the 8086's 16-bit one, twice as fast).

Please feel free to correct or add any info to this!

---
Know your limits.h

> ... I heard that a 386 Sx had a 16-bit external data bus vs. 386 DX
> and all 486s (even Sx) which have a 32-bit one.

Correct.

> And the Pentium has a 64-bit one, last I heard.

There are both 32-bit and 64-bit Pentiums.

> Plus, the original IBM PC was an 8088 and had an 8-bit one (vs. the
> 8086's 16-bit one, twice as fast).

8088 is 8-bit internal and external. 8086 is 16-bit internal and 8-bit external - designed to retain adaptability to older mainboards (like 386SX later). The 80286 introduced full 16/16.

> > Plus, the original IBM PC was an 8088 and had an 8-bit one (vs. the
> > 8086's 16-bit one, twice as fast).
>
> 8088 is 8-bit internal and external. 8086 is 16-bit internal and 8-bit
> external - designed to retain adaptability to older mainboards (like 386SX
> later). The 80286 introduced full 16/16.

That's wrong. The 8086 already is a 16/16-bit CPU. The 8088 is limited to an 8-bit external data bus.

---
Forum admin

> > > Plus, the original IBM PC was an 8088 and had an 8-bit one (vs. the
> > > 8086's 16-bit one, twice as fast).
> >
> > 8088 is 8-bit internal and external. 8086 is 16-bit internal and 8-bit
> > external - designed to retain adaptability to older mainboards (like
> 386SX
> > later). The 80286 introduced full 16/16.
>
> That's wrong. The 8086 already is a 16/16-bit CPU. The 8088 is limited to
> an 8-bit external data bus.

I should have checked the old data, rather than depend on my failing mamory of antique CPUs:

*8080* is 8-bit internal and external. 8088 is indeed 16/8, and 8086 (older than 8088 but used by IBM later), not 80286, introduced full 16/16.