X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: CWSDPMI questions [was Re: Charless Sandmann] Date: Sun, 24 Feb 2002 14:09:39 CST Organization: Rice University, Houston TX Lines: 105 Message-ID: <3c794883.sandmann@clio.rice.edu> References: NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1014583647 11832 128.42.105.3 (24 Feb 2002 20:47:27 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: 24 Feb 2002 20:47:27 GMT X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > What about changing PD and PT. Is it harmfull to CWSDPMI or my > program when I change some PD or PT entries? As long as you know what you are doing you can change the Page Directory and Page Tables as much as you would like. Once they are changed you need a mode swap (calling an interrupt, for example) to get the changes loaded. This feature has been used to rearrange fragmented physical memory pages (under emm386) to create a contiguous memory area suitable for DMA usage. > I'd like to map whole (or fragment) DOS (0-1MB) memory > to my virtual address space. > (I allocate 1MB of memory, commit all pages, lock this region, > go thorugh PD and PT changing physical addresses to point to > DOS memory) There is actually a DPMI 1.0 extension interrupt which CWSDPMI supports which will do this for you. (See dpmi function 0x508). I think you could do the entire 1Mb area in a single call - but it may leave the cache bits turned off. But it's easier to flip those after mapping than set up the entire thing. > I'd like to map APIC register space to my program > virtual address space. > > I've tried this before and it worked, but I'm not sure about > consequences. > > Doing this I make some silent assumptions: > +cwsdpmi won't change my program base linear address Correct, unless you specify unixy sbrk() and allocate a DPMI memory block after a the block containing your program and then ask to increase it's size. The resize request would be forced to move it. Very rare, and only if you do several things to shoot yourself. > +cwsdpmi won't remap this modified linear fragment to other physical > address Not unless it's in the way of something else you ask it to do. > +cwsdpmi will be able to allocate memory if asked by DJGPP libc This shouldn't be a problem, unless you need lots of memory (ie >256Mb) and the address of the devices you are mapping gets in the way. Once again, very rare. > If answer for some of these questions is NO maybe there is way changing > this answer to YES? With the source, there is always a way to fix it :-) > I'd like to install RM interrupt in the same way as I did in PM ( > directly via IDT) > I assume that I've service routine in DOS memory. > > Now I can put its address directly into Interrupt Vector Table (IVT). > But where is it? Where begins IVT for real mode interrupts? > Does it still begin at 0000 or it's moved somewhere? Yes, the real mode interrupt table is at address 0 in physical/linear memory, and that's where the real mode interrupt routines would need to be set. > Now I think it's sufficient to put address of my ISR to this table, > and everything should work fine AFAIR (I've never tried so far) > As in PM case CWSDPMI won't even see this interrupt when it arrives > and will get served by my RM ISR. CWSDPMI has it's own hooks into the RM table - so if you overwrite them it will never attempt to call it's routines. CWSDPMI does reprogram the PICs to interrupt on different values. It should be transparent, but you can save a few extra cycles by hooking the right one instead of being bounced to it. > What abount NMI? I intend to use Local APIC and some "Local interrupts" > Some interrupts generated by APIC must be carried as NMI. > Is it possible to crash CWSDPMI by NMI interrupt? NMIs are passed like regular interrupts to the appropriate interrupt routines. There are some places which CWSDPMI does not like to be interrupted since it's not reentrant there. Simple things shouldn't kill it, but if you do something complex in an NMI in exactly the wrong spot, I'm sure it's possible to cause something bad to happen. This hasn't been looked at in detail. NMI handling was improved in r4? r5? so that it didn't cause problems on some applications - but I didn't look at it after doing what users requested to fix it. > When mode is switched from PM->RM there is moment when > LDT (by LIDT instruction) must be loaded, so there is very short > (but IS) time, when IDT is invalid. > Since NMI interrupt cannot be masked, there is possibility > (very small, but IS) that everything will crash - I think. This is possible - but in that time the IDT is pointing to the one for the other mode (real/PM). I don't think this is only only bad possibility. In reality, some people have used it in ROM applications using NMI without problems (maybe just lucky...) > If I'm right is this really dangerous? > Maybe probability of this is very small e.g 10^-50 ?? It all depends on the number of NMIs and the frequency of mode swaps, so your guess is as good as mine.