Guys,
Yeah, it clearly will be the best for me to use XMS functions. There is
still a lot I don't know about the different ways to access PM memory
(including protected mode itself) so some things you guys say are perfectly
clear to me while others are full of mistery :P Is there any site where I can
read in very good detail and in a way that is easy to understand, how flat-real
mode, VCPI and DPMI work and how they deal with other previously loaded systems
to avoid collisions?
I really want to learn all that and whenever I find info on that it's rather
cryptic. If one or more of you are willing to give me some "lessons" over Skype
or something, I am willing to be very cooperative :P ha, ha. I really want to
learn this thing.
DOS386 mentioned "if you want PM, you have VCPI", I think, meaning if I
wanted to access PM memory. If that is the case, that line is indeed very
significative to me! Only I wish I knew more about VCPI. Because of the nature
of my driver, the memory access does not have to be very messy and it will
probably be enough to just rely on XMS functions for now.
One doubt I have about XMS functions is this: the XMM specification states
that if I lock some memory, I must unlock it as soon as possible. How soon is
that? What exactly is a lock count? I may, for many things, not need to know
where my memory block is located, but sometimes, when I do need it, it would be
important to keep it locked for as long as the driver is running, because it is
a driver and other programs would be relying on it. Can I keep memory locked
like for the whole time one process is running (i.e.: half an hour)? How bad
is that?
About what hardware the driver is for... well, it's not for just one piece
of hardware. What I am working on is a spec to link different APIs for
different pieces of hardware and software. The idea is that all the elements
can be accessed together in the same way and at the times they are really
needed. This would keep as much free conventional memory as possible at all
times, allowing dynamic modules and also providing a connection with a
call-point and parameters that could be projected on any software/hardware
platform. For example, we could use an interrupt number, say, 49h and registers
EAX trhough EDX... but we could also use a PM pointer to code memory to be
called with the parameters pushed into stack, etc.... and the spec would still
hold. The result is that any operating system and any computer would be able to
use the same structure (if they were interested) and OSs who participate in it
will be able to help one another instead of working
separatedly. It goes further, but I would need to write a whole document to
explain my exact idea, so I want some code running, before I present it neatly.
What do you reckon?
Lucas
--- On Fri, 30/10/09, Christian Masloch <c...@bttr-software.de> wrote:
From: Christian Masloch <c...@bttr-software.de>
Subject: Re: [Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and
interrupts
To: freedos-devel@lists.sourceforge.net
Received: Friday, 30 October, 2009, 1:16 PM
>> but then virtual-86 mode is set and I can no loger use 32bit real-mode
>> pointers!
>
> IF you need PM from V86 there is VCPI.
Protected mode isn't the same as flat real mode.
>> Yet, there has to be a way, because HIMEM works even though EMM386 is
>> loaded.
>
> As said, it uses INT $15 / AH=$87 then. That's also what you can use
> to access
> PCI memory mapped I/O (>= 2 GiB) from real mode code, even if EMM386 is
> there.
>
> BTW, RBIL is wrong here, it says "linear address" but the call in fact
> eats
> physical addresses, at least those above 1+1/16 MiB AKA $0011'0000.
Yes, you're right. All areas above the 1088 KiB (- 16 byte) accessible in
real mode access the physical memory. Since the XMM works by switching to
protected/flat real mode (without remapping memory) or using Int15.87
provided by EMM386, the linear address returned when locking a XMS memory
block should be usable as physical address as well.
Regards,
Christian
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
