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 BlackBerry
Re: [Freedos-devel] Pre-presentation of a project
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, 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
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
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] Pre-presentation of a project
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 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
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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
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] 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
