Re: Re: DRL updated! -- please stop that INT discussion!

> BUT DR emm386 is free for noncommercial use 

I can't hear that any more. DRDOS is free for noncommercial use.
use it as you like. I have heard that advertising of DR-emm386 a couple
of hundred times; now you might stop this spam.
this is the FreeDOS list  =:->

> Freemm386.org is
> a project that tries to do everything from scratch without help from
> external sources. For this reason, they will take ages :-(. 

and scince it's definitively dead, it will take even longer.


> If you need protected mode AND umb, try any of the cousins of UMBPCI,
> and if none works, help improving them so that they work for your
motherboard
> chipset.
a) UMBPCI source isn't available
b) the UMBPCI does what he can, but some chipsets don't support what UMBPCI

needs 

> My problem is not only about porting DRL to protected mode. My real
> problem is as follows:
> 
> mov [opcode+1], interrupt number
> opcode: int 00

this is a variant of
	 mov [opcode+1], some number
 	 n times NOP
	 opcode: mov ax, 00

this type of code was used (and working) for all processors <= 386 (IIRC) 
to measure the size of the prefetch queue - probably not what you wanted.

at least a jmp instruction is missing like
	 mov [opcode+1], some number
 	 jmp opcode
	 opcode: mov ax, 00

> the v86 monitor slightly changes the
> behaviour of the prefetch mechanism of your processor.


v86 monitors to an astonishing amount of things, but they certainly
dont change the prefetch behaviour of your processor (however - in theory -
real mode and V86 may be different implemented by your processor)


> Preparing an INT on stack is certainly good for ROM ability, but it is
> even better to just:
> 
> pushf
> cli
> call far "where the vector of interrupt number xyz points to"

that's NOT the same - as you explain below.
in particular, INT 67 is INT 67, NOT pushf/callf

additionally, v86 monitors have to handle some more interrupts - 
(like int15/87).
please don't advertise incompatible nonsense (because it works)
- and wonder later that it doesn't work anymore.

> The only interrupt that causes troubles for emm386 type v86 monitors is
> int 67h ($67, 0x67, as you like :-)), and for this, there is the elegant
> solution mentioned above already implemented in almost all emm386
drivers.
'almost all' -> it worked in MS-EMM386, so it was used by *some* guy, 
so it had to be supported by the other EMM's, too.

tom