Re: [Freedos-devel] Pre-presentation of a project
Ladislav, I agree. Miles is probably the most common sound interface ever used in DOS and no other so far could be called a standard. There is also HMI who is pretty common as well, but I know very little about. Mr. Miles has been very attentive in answering my e-mails. He explained me that the MSS no longer belongs to him and that most of the information, he is unable to disclose, but that if he may be able to help, he'll get me what he can. He also answered many of my questions. Of course, MSS is totally commercial, but I want to point out how important it is to put attention to how it works. My approach, so far, as regards the Miles Sound System, is only to build a patch... a half-driver that can be placed where applications expect to find the MSS, and which will redirect the output to the actual sound driver. In the spec I'm developing, I've called the main driver dimi-driver and the patch teri-driver. I also refer to theoretical emulation drivers as semi-drivers, that would also redirect the output to the dimi-driver, although I am not thinking of developing one. These names are arbitrary and chosen only for the sound of the words (except Dimi, which is my cat's name, he, he). Although the teri-driver development is something I'm desperate to work upon, I am conscious on how important it is to leave such task for the moment that at least one dimi-driver is ready. I'm currently working on the main CPOS interface, where the NSS module (a dimi-driver) and the Code-1 module (Unicode support) are going to be hooked. I have been modifying some things I've realised that are not good as I originally planned them. Lucas --- On Mon, 2/11/09, Ladislav Lacina la...@seznam.cz wrote: From: Ladislav Lacina la...@seznam.cz Subject: Re: [Freedos-devel] Pre-presentation of a project To: freedos-devel@lists.sourceforge.net Received: Monday, 2 November, 2009, 10:31 PM I want to react to part about the sound system.. I also strongly advocate Miles sound system in various discussions about DOS sound interface. It is modular, many programs and games support it and new drivers for new PCI and integrated cards can be written for it. The DigPak/MidPak more or less only different name for DOS part of Miles sound system. -- 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-de...@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
Re: [Freedos-devel] Pre-presentation of a project
Christian, As I said, how the interface works particularly for FreeDOS is arbitrary, and interrupt 2Bh was only a suggestion. I agree that saving a whole interrupt for what now is just one project is kind of selfish. There are plenty of solutions to this. Just as you reply, it could also be slow to handle the services inside AMIS and passing the direct address would be much better. The main information about the driver and the setup could be handled by the AMIS interface, though. I believe passing the parameters in memory would also slow down considerably for functions that need to be called repeatedly in brief periods of time and that's why I think registers could be better. However, my spec does already support an alternative way to pass parameters (that I called parameter transfer gate), so both things can actually be done. I'm thinking that I can perfectly get an interrupt, without having to reserve one. That is, a function under AMIS could tell the driver to get hooked at a certain interrupt chosen by the caller. This would be more comfortable for the high-level programmer than having to call an absolute address. When I said already multiplexed, I meant that my driver is itself a multiplexed system, because it can load and unload modules and manage their functions. The modules are not TSRs that have to load on top and create a chain, but instead, are dynamic and are called in parallel. Their codes are never executed unless a specific function is invoked and the modules only remain in memory while in use. About sound. Yes, programmes that do not use a third party sound system and go straight to the ports have no other way to support new cards than through a port emulation or by being modified. If the application supports AdLib, however, it is very easy to locate in the code, the points where the ports are accessed. It would not be hard work to redirect this code to the driver. Anyway, I don't think that is necessary. The reason is that old DOS applications that use sound can be divided in games and non-games: oldest games are the ones that do not use 3rd party drivers, but the easiest to modify and most support PC speaker anyway. For non-games, it is not important to maintain sound support, unless they are sound players or stuff like that, in which case, we can create new and better ones now (for a non-game, no nostalgia :P, no need for it to be the same). Lucas --- On Mon, 2/11/09, Christian Masloch c...@bttr-software.de wrote: From: Christian Masloch c...@bttr-software.de Subject: Re: [Freedos-devel] Pre-presentation of a project To: freedos-devel@lists.sourceforge.net Received: Monday, 2 November, 2009, 3:02 PM The reason why I've been considering a brand new interrupt is because the driver is not supposed to be single-purposed. This does not convince me. What I want to create is a new standard interface where support for new features can be hooked in a very tidy and organised way. I think we can't just keep on adding functions to the int 21h, because ... almost all functions are already used and really, assigning fixed function numbers is no way to go anymore. But anyway, we didn't talk about Int21. although I know of AMIS and I find it very flexible and useful, the interface is again to big to be put inside an already multiplexed system. What do you mean here? Do you think there aren't enough available functions? Then pass the function number in other registers (besides ax) too. Or do you mean it won't be fast enough to call all functions through Int2D ? Then let applications request your real entry point with an AMIS function on Int2D and provide your own interface at this address. I don't see why you have to allocate another fixed interrupt for this. I thought of ints 2Bh and 2Ch Int2C has been used by Cloaking, kind of a DOS extender. within the range of the DOS interrupts and the driver would be a field on which to extend DOS, but it could also be done with other interrupts. Basically, it doesn't matter. Packet drivers and EMM386 use interrupts 60h and yet they're considered DOS extensions. This spec has a list of general functions and general parameters which is independent from software and hardware. Consider passing a request structure to the interface then. Opposed to specifying interrupts to be called and registers to be used, this could easily be adapted for other architectures. I could create patches to replace these drivers and take the output to the new module. DOS would have sound again... always, and without need of port emulation. Except with existing programs that directly access the hardware and don't use any of these specifications. Regards, Christian -- Come build with us! The
Re: [Freedos-devel] Pre-presentation of a project
Christian, I'm working on it now. Users will not have to search for an available interrupt. The driver will do that for them. I'd better put up the code. I don't want to be all theory up here. But you're right about taking advantage of the AMIS. Even though you first said I shouldn't change my project just because some people may not like it, and I agree, I also believe it is very important to check with you guys and to be constructively criticised here. This way, I can make my code something many people will find useful, attractive and comfortable to use. When I say parallel (and I know this is not the best term, anyway), I mean that, as a module is activated and a user calls a function in that module, the dispatcher will not go one by one through the function numbers, but will just jump to the specific module. It will be up to that module code whether to do a chain comparison at this point or to use XLAT to load the function address from a table, which is a good idea if the functions are many. The loading of modules could theoretically be done from the disk, but I think the best thing is to keep them in XMS and load them into conventional memory only when required. A foreground application can load the modules from disk to XMS and the driver will handle them while other programmes request the functions. Of course, the main module is itself a TSR and TSRs could perfectly work in this fashion, but it is not what usually happens. I normally see new code hooking up an interrupt, making a function ID comparison at the beginning and jumping to the old handler if this is not the function it is interested in. This generates a slow serial chain of handlers. I want to avoid that. If the game supports SB or AdLib sound, the PC speaker output won't be as good as the SB/AdLib one. Right, but very old games usually only support PC speaker. If they do support another hardware, it is most commonly AdLib, which only uses two ports. The code is easy to crack. The OUT instructions can be located where the specific ports are used (the MOV DX,port usually is very close to the OUT). Some games, such as Stunts, use their own sound drivers but still put them in separate files. In the case of Stunts, the AdLib driver is a file of no more than 2KiB. This can be disassembled (Stunts can be freely distributed now) and a patch can be made to replace it, even though Stunts does not rely on Miles, HMI or DIGPAK. I'm pretty confident that I can get at least 50% of the old games to get to the driver in one of these ways. OK. I'll work on the AMIS interface for the first implementation of the main module. I'll post it when I have it and then start the Code-1 and NSS. Lucas --- On Tue, 3/11/09, Christian Masloch c...@bttr-software.de wrote: From: Christian Masloch c...@bttr-software.de Subject: Re: [Freedos-devel] Pre-presentation of a project To: freedos-devel@lists.sourceforge.net Received: Tuesday, 3 November, 2009, 1:23 PM I'm thinking that I can perfectly get an interrupt, without having to reserve one. That is, a function under AMIS could tell the driver to get hooked at a certain interrupt chosen by the caller. This would be more comfortable for the high-level programmer than having to call an absolute address. No. It might be more comfortable for a low-level (i.e., Assembly) programmer. It doesn't make a difference in high-level languages. Also, the caller would have to find a free interrupt at run time, which might create new problems. When I said already multiplexed, I meant that my driver is itself a multiplexed system, because it can load and unload modules and manage their functions. Okay. The modules are not TSRs that have to load on top and create a chain, but instead, are dynamic Which is different from TSRs in what way? TSRs don't have to be restricted to load in a specified order. and are called in parallel. Do you mean they're called in the background? What does parallel mean here? Their codes are never executed unless a specific function is invoked and the modules only remain in memory while in use. So you have to load them from the disk when they're requested? I don't object to this approach generally, but keep in mind that loading files must happen in the foreground. Anyway, I don't think that is necessary. The reason is that old DOS applications that use sound can be divided in games and non-games: oldest games are the ones that do not use 3rd party drivers, but the easiest to modify and most support PC speaker anyway. If the game supports SB or AdLib sound, the PC speaker output won't be as good as the SB/AdLib one. About patching old games: Maybe you're right about this and it'll work for most games. Either way, I'm looking forward to an implementation of this architecture. Regards,
Re: [Freedos-devel] Pre-presentation of a project
Thanks, Megabrutal I did not know that was happening. Of course, my own e-mail does not put my messages into Spam, so I did not see it. I figure some other people may or may not be getting them into spam, depending on their provider also. Probably this has to do with the things Yahoo adds at the foot of my messages. I have removed all HTML tags and wiped the foot of the quoted message. Let me know if this still goes to SPAM. Thanks again, Lucas --- On Mon, 2/11/09, MegaBrutal megabru...@gmail.com wrote: From: MegaBrutal megabru...@gmail.com Subject: Re: [Freedos-devel] Pre-presentation of a project To: freedos-devel@lists.sourceforge.net Received: Monday, 2 November, 2009, 8:56 AM Lucas: sorry for the off-topic, but for some reason, GMail always puts your letters to SPAM. I don't know why, but it's possible it doesn't like your e-mail service, or finds suspicious samples in your mails. If you can, please try to do something about it. And again, sorry for the off.. I send it publically, because others might suffer the same thing, and maybe there is a clever person on the list who knows the reason, why are your e-mails go into spam, and can help you out. -- 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
Re: [Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and interrupts
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'. 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
[Freedos-devel] Pre-presentation of a project
Guys, I am currently working on a project for DOS and I hope the FreeDOS community will find it useful. I was trying not to present it until it consists of a significant running piece of code, because I don't want it to sound virtual, but as I ask for help here, people ask me details about it and I believe it is fair for you to know more if I am needing your help or answers. I know that the main objective in FreeDOS is to provide a working classical DOS environment and not to turn into something else. I do not intend to go against that aim. However, I do believe that there are some important points that do not have any support within classical DOS at all and for which a standard should be implemented. I am trying to supply that standard in a way that will not collide with classical DOS, that is, the same code will run the same way, but applications will have the option to also rely on a driver and some modules. I have been asking questions here to implement two of these modules (namely Unicode support [or Code-1 module] and a new native DOS sound interface [or CPOS/NSS]). The driver (CPOS) would be loading a main module into conventional memory that would dispatch functions and separate them in knots, each of which would redirect to a child module. These modules can be programmed separately, but I would like to create at least two if them to be presented together with the main one as the first issue of CPOS. The purpose is not only about supporting these items, but about doing it in a way that can easily be implemented from different software and hardware platforms and still satisfy the standard. This would mean that, for example, one single guy might come up creating his own small operating system somewhere, without any support from anybody and decide to follow the CPOS standard. If he does so, he would be able, after a few modifications in the source code, to recompile modules already made for another OS and use them in his, so he would have, say, sound support in his OS without having to research and program everything himself. Additionally, if he would develop a module for, say, DVD burning, FreeDOS could use his source and recompile it so that it could be loaded and hooked at a knot in DOS/CPOS. In other words, all hobbists in OS would be able to cooperate and still we would have diversity, because each OS would use their own method to provide CPOS. In particular, for FreeDOS, I have been thinking this could be applied on a real mode interrupt (maybe 2Bh, but could also be 50h) with the parameters passed as registers, as it is usual in DOS, but other ways could be used instead. If any of all this sounds silly, I must apologise that I have not been able to be specific enough here or describe exactly how the driver would work, as I am not providing code right now, but I will eventually do and I am from this moment appreciating any suggestion, comment or question. Thank you very much in advance for your help and sorry about my not being able to upload a neat piece of code right now. Lucas -- 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
Re: [Freedos-devel] Pre-presentation of a project
Thanks, Christian, The reason why I've been considering a brand new interrupt is because the driver is not supposed to be single-purposed. What I want to create is a new standard interface where support for new features can be hooked in a very tidy and organised way. I think we can't just keep on adding functions to the int 21h, because that's where the classical DOS interface lays and although I know of AMID and I find it very flexible and useful, the interface is again to big to be put inside an already multiplexed system. I thought of ints 2Bh and 2Ch because they are within the range of the DOS interrupts and the driver would be a field on which to extend DOS, but it could also be done with other interrupts. Single-purposed applications should not use this interface. For that, there is AMID and int 2Fh. This is only for general hardware and software support. I am currently writing the first CPOS main module in Flat Assembler, but the spec is not closed to the x86 architecture. Any driver able to respond to the CPOS functions would be a CPOS, regardless of the language, encoding or calling platform it uses. That is the idea. I want to keep OS diversity and at the same time add compatibility, which seems at first sight contradictory. Although the code is of course a must, the project itself does not consist of code, but of the specification. This spec has a list of general functions and general parameters which is independent from software and hardware. Attached to it, there are modules that are hooked in knots. To make the interface useful, I want to first implemented with two module prototypes: one for Unicode and another one for sound support. I believe these two things are maybe some of the most important things DOS is needing right now.. The Unicode support functions (Code-1 module) will let the user print Unicode strings on the screen in graphics mode (and up to some extent in text mode), convert between ASCII, UTF-8, UTF-16 and UTF-32 and handle individual Unicode key-buffers customised for the running application. The buffers could be sequential (like the BIOS keyboard buffer) or parallel (like the ones used by ISRs that games install in memory). It will be very important to cooperate with KEYB and DISPLAY. I have already been exchanging some words with some of the guys about that. Huge conversion tables will have to be in memory and, when handling graphic modes, also fonts will have to be loaded. The sound system (NSS module, or New Sound Standard), I divide in blocks of functions. Some will handle the module configuration, others sampling, music, sound table and mixer. Each block can be redirected to a piece of hardware or to another block (for instance, you might not have a sound table, but could use some software to redirect the sound table directly to the DSP). Modules with these functions would be the main part of it. Then I have some plans for another type of driver that would be used to allow old applications redirect to the CPOS/NSS module. To accomplish this, I have been researching on the sound systems different games use and found that most of them use the Miles Sound System, Human Machine Interface or some Creative drivers like CT-VOICE and SBFMDRV. It is also common to find DIGPAK and MIDPAK. I have the documentation for these last four APIs and I have exchanged some e-mails with Mr. Miles about the first one. I could create patches to replace these drivers and take the output to the new module. DOS would have sound again... always, and without need of port emulation. But that will be a lot of work. If you're interested, I will be pollishing the spec and sending you a very small and raw code and source of the main module implemented particularly for FreeDOS and for the x86. You may say I'm a dreamer, but I'm not the only one... am I? :) Lucas --- On Sun, 1/11/09, Christian Masloch c...@bttr-software.de wrote: From: Christian Masloch c...@bttr-software.de Subject: Re: [Freedos-devel] Pre-presentation of a project To: freedos-devel@lists.sourceforge.net Received: Sunday, 1 November, 2009, 10:33 AM I was trying not to present it until it consists of a significant running piece of code, because I don't want it to sound virtual I know what you're talking about here. I know that the main objective in FreeDOS is to provide a working classical DOS environment and not to turn into something else. I do not intend to go against that aim. However, I do believe that there are some important points that do not have any support within classical DOS at all and for which a standard should be implemented. I am trying to supply that standard in a way that will not collide with classical DOS, that is, the same code will run the same way, but applications will have the option to also rely on a driver and some modules. Please don't restrict your project just because some
Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts
Guys, I was pretty sure I had got it working before, so I didn't want to just leave it as it is. What I just did is restart my computer with plain FreeDOS and wrote, compiled and executed a programme like this: mov ax,0b800h --- On Tue, 27/10/09, japhethx gmail japhe...@googlemail.com wrote: From: japhethx gmail japhe...@googlemail.com Subject: Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts To: freedos-devel@lists.sourceforge.net Received: Tuesday, 27 October, 2009, 4:56 PM However, I understood that HIMEM did something like establishing a routine that was run whenever you tried to use an offset greater than 0h together with a real-mode-made segment. This routine would trap the event and handle the switch to protected mode and back, keeping the segment base, but extending the limit to 4G, then returning to the instruction that generated the exception. Am I right? Does this really happen? If so, programs should not mind about their segments being initially setup in real mode. No, I'm not aware of any Extended Memory Manager (XMM) that does such a thing. MS Himem does indeed install such a routine, but it is installed only during XMS block moves inside Himem. See the MS Himem source for details. It's Public Domain, IIRC. -- 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
[Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and interrupts
Guys, I was pretty sure I had got it working before, so I didn't want to just leave it as it is. What I just did is restart my computer with plain FreeDOS and wrote, compiled and executed a programme like this: mov ax,0b800h mov ds,ax mov word ptr [100h],1f21h ; draw exclamation mark mov ax,[12345678h] ; tempt FreeDOS to respond to an exception mov word ptr [102h],4e3fh ; draw a question mark mov ax,4c00h int 21h ; exit to DOS What happened was that both marks where drawn and no error occurred. At that point, only HIMEM was loaded, no EMM386. I thought that meant that FreeDOS's HIMEM did indeed have that routine. I rebooted the computer with EMM386 and reran the program. Of course, this time, an exception was triggered. Only the exclamation mark was drawn and the program exited abnormally. This was quite sensible to me. I tried one more time not loading any of the two drivers. The first mark was drawn again, but the system halted, unable to handle the exception. Then I decided I'd be more drastic, so I wrote another program like this: xor ax,ax mov ds,ax mov word ptr [0b8100h],1f21h ; draw exclamation mark mov ax,4c00h int 21h ; exit to DOS When loading only HIMEM, this did, in fact, cause a mark to be drawn on the screen. But then I realised it could also be the fact that I was using 4DOS as the command interpreter. So I rebooted with HIMEM and FreeCOM and the system hung when I tried to execute the code. Conclusion: it was 4DOS that was loading this routine and not HIMEM, but as I had read at some point about HIMEM.SYS doing it, I had thought that was it in this case. Anyway, this leads me to think it'd be very handy to have a function or a small application in DOS to enable this behaviour on programmes requests. Of course, relying on this would render code incomaptible with EMM386 and emulators such as DOSBox. Am I right? On the other hand, it would be a lot faster to access memory. Lucas PS: Because of a problem with yahoo, you may have received a truncated copy of this e-mail. Please disregard it. I think I'll switch to GMail --- On Tue, 27/10/09, japhethx gmail japhe...@googlemail.com wrote: From: japhethx gmail japhe...@googlemail.com Subject: Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts To: freedos-devel@lists.sourceforge.net Received: Tuesday, 27 October, 2009, 4:56 PM However, I understood that HIMEM did something like establishing a routine that was run whenever you tried to use an offset greater than 0h together with a real-mode-made segment. This routine would trap the event and handle the switch to protected mode and back, keeping the segment base, but extending the limit to 4G, then returning to the instruction that generated the exception. Am I right? Does this really happen? If so, programs should not mind about their segments being initially setup in real mode. No, I'm not aware of any Extended Memory Manager (XMM) that does such a thing. MS Himem does indeed install such a routine, but it is installed only during XMS block moves inside Himem. See the MS Himem source for details. It's Public Domain, IIRC. -- 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 Reading this email at work? Make a change with Yahoo!Xtra Jobs -- 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
Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts
Thank you, Christian You've cleared out some doubts and misunderstandings I had. Still, now this leads me to new questions. Also, I would like to clarify some of the things I wrote in my last e-mail. When you say a program would still need to set up flat real mode, I suppose you mean that they still need a jump to protected mode and back to initially setup the segment registers. However, I understood that HIMEM did something like establishing a routine that was run whenever you tried to use an offset greater than 0h together with a real-mode-made segment. This routine would trap the event and handle the switch to protected mode and back, keeping the segment base, but extending the limit to 4G, then returning to the instruction that generated the exception. Am I right? Does this really happen? If so, programs should not mind about their segments being initially setup in real mode. I agree that using the EMS functions would make the interface lack of good compatibility and would like to avoid that. What I don't want is to do something that will not work if EMM386 happens to be running. I believe that, while EMM386 is running and the system is in virtual-86 mode, it is no longer possible to extend the segment limits to 4G and they will always generate the exception. This makes me wonder how come everything still seems to run properly (programs that use XMS) when EMM is there. My driver is a set of functions that use 32-bit registers and runs hooked on a single interrupt. Sometimes the caller will provide a pointer to a buffer and the functions will fill these buffers, but also, some very big tables have to be loaded, that can occupy as much as one or two megabytes.. I could do moving parts of them to conventional memory as needed, but it would be faster if I could access them directly somehow. The driver leads with a sound interface sometimes and needs to set up big buffers that, depending on the sound card, may have a fix hardware address beyond the conventional and high memory limit. Basically, the driver may return pointers to these areas, but could also copy the data to a buffer provided by the caller. Do you think I should write the functions like pure real-mode code that accesses HIMEM XMS functions as needed to move the data? Would that be entirely compatible with real-mode- as well as DPMI-applications calling the functions? If so, how should I handle the events when I need to read or write in a fixed extended memory area? Is it better to always ask the caller to provide buffers or is it more efficient (and safe) to return pointers to the buffers? In some cases, the problem is that one buffer is to be used by many applications (i.e.: a running program and a couple of TSRs in memory) and having the caller create a buffer would mean the driver would have to update several identical buffers instead of getting all tasks refer to the same one. That would not be practical and would use up more memory. Well, I think I've got into big trouble building this driver! I hope at least I learn a lot in the process. Thanks in advance for any more hints you can give me, Lucas --- On Mon, 26/10/09, Christian Masloch c...@bttr-software.de wrote: From: Christian Masloch c...@bttr-software.de Subject: Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts To: freedos-devel@lists.sourceforge.net Received: Monday, 26 October, 2009, 3:28 PM I'm building a driver (for DOS) that's supposed to have several functions hooked at an interrupt. When applications call these functions, the driver should load and unload some tables or activate/deactivate them somehow. Because these tables are big, I don't want to keep them in conventional memory with the driver code altogether, but instead prefer them to by dynamic. The problem is as follows. If I want to have the tables in files, then loading them in and unloading them from conventional memory will cause several problems, which include slowdowns, risk of instability because of hard-drive access and a big amount of conventional memory still occupied while the tables are in use. I want, therefore, have the tables permanently loaded in high, extended or expanded memory while the driver is running. I'd disregard EMS (expanded memory), or at least depending on EMS. It's supported when installing an EMM386 (+HIMEM) only, and if the user switched it on. If you still want to use EMS, write your program so that it doesn't need a page frame if running under the correct EMM. But this means that the driver will have to do different things to get to the tables depending on whether HIMEM, or EMM386, or both, or none of them are currently there. Your program can't check for EMM386 or HIMEM, it can only check whether XMS or EMS is available. I am really not very experienced with high memory, but I understand that, even without HIMEM
[Freedos-devel] About my driver, HIMEM/EMM386 and interrupts
Guys, I'm building a driver (for DOS) that's supposed to have several functions hooked at an interrupt. When applications call these functions, the driver should load and unload some tables or activate/deactivate them somehow. Because these tables are big, I don't want to keep them in conventional memory with the driver code altogether, but instead prefer them to by dynamic. The problem is as follows. If I want to have the tables in files, then loading them in and unloading them from conventional memory will cause several problems, which include slowdowns, risk of instability because of hard-drive access and a big amount of conventional memory still occupied while the tables are in use. I want, therefore, have the tables permanently loaded in high, extended or expanded memory while the driver is running. But this means that the driver will have to do different things to get to the tables depending on whether HIMEM, or EMM386, or both, or none of them are currently there. I am really not very experienced with high memory, but I understand that, even without HIMEM or EMM386, I can access high memory by setting up real-flat mode. Also, if HIMEM only is there, this mode is already available and I can easily access the tables without having to move memory (that is, using 32bit pointers in real mode instead of calling HIMEM functions to copy data). If EMM386 is loaded, I know I can use the expanded memory functions, but then virtual-86 mode is set and I can no loger use 32bit real-mode pointers! Yet, there has to be a way, because HIMEM works even though EMM386 is loaded. This clearly shows me that there is a big deal of things I don't know about these two drivers! I need help understanding how these two drivers work, as well as what happens in real-flat and virtual-86 modes. I also need to know how I can make my interrupt functions flexible enough so that they can work no matter which HIMEM/EMM386 is currently working and, if possible, I would like my functions to also be compatible with protected mode (DPMI) applications calling them, because the functions have to access memory and return pointers and therefore, might not work by using real-mode-interrupt calling functions of the DPMI. Can anybody help me with all this, please? :) Lucas -- 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
