Pre-presentation of a project

[Lucas Kiwi]

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

Email slow, clunky, unreliable? Switch to Yahoo!Xtra Mail, New Zealand's new email address.
------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Christian Masloch]

> 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 people might not like  
it, thank you.

>    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.

What does the Unicode support do? What tables or services are provided by  
it?

>    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.

And in what language do you implement CPOS? I mean, is it restricted to  
386 architectures (i.e. Assembly)?

>    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 you search a real mode interrupt, you might consider providing your  
interface on Int2D and following the Alternat(iv)e Multiplex Interrupt  
Specification (AMIS). This often provides other TSRs and your driver with  
the possibility to remove the TSR, and Int2D isn't used by something else.  
The most recent AMIS can be found inside the RBIL; read the descriptions  
of the Int2D functions.

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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Lucas Kiwi]

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 <cm@...> wrote:

From: Christian Masloch <cm@...>
Subject: Re: [Freedos-devel] Pre-presentation of a project
To: freedos-devel@...
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 people might not like 
it, thank you.

>    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.

What does the Unicode support do? What tables or services are provided by 
it?

>    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.

And in what language do you implement CPOS? I mean, is it restricted to 
386 architectures (i.e. Assembly)?

>    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 you search a real mode interrupt, you might consider providing your 
interface on Int2D and following the Alternat(iv)e Multiplex Interrupt 
Specification (AMIS). This often provides other TSRs and your driver with 
the possibility to remove the TSR, and Int2D isn't used by something else. 
The most recent AMIS can be found inside the RBIL; read the descriptions 
of the Int2D functions.

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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Email slow, clunky, unreliable? Switch to Yahoo!Xtra Mail, New Zealand's new email address.
------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[MegaBrutal]

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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Christian Masloch]

>    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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Ladislav Lacina]

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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Lucas Kiwi]

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 <megabrutal@...> wrote:

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

[Lucas Kiwi]

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 <laaca@...> wrote:

> From: Ladislav Lacina <laaca@...>
> Subject: Re: [Freedos-devel] Pre-presentation of a project
> To: freedos-devel@...
> 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-devel@...
> 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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Lucas Kiwi]

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 <cm@...> wrote:

> From: Christian Masloch <cm@...>
> Subject: Re: [Freedos-devel] Pre-presentation of a project
> To: freedos-devel@...
> 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(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@...
> 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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Christian Masloch]

>    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@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Lucas Kiwi]

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 <cm@...> wrote:

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

     


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Christian Masloch]

> I'd better put up the code. I don't want to be all theory up here.

I'm fine with theoretical discussions.

> 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.

Well, it should certainly be your decision. No matter what, some people  
(possibly including me) won't like it. If you prefer things I don't like,  
please don't change them just to satisfy me.

>    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.

Your interface (as I understand it) isn't that different. Somewhere you  
have to dispatch into different modules.

>    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.

If you're interested, I could send you descriptions and example source of  
some TSRs and AMIS implementations that I worked out with Bret. This TSR  
installation method always allows the program to install its resident part  
into the best location. Installation into a UMB works without LOADHIGH.  
The deinstallation method allows to remove the TSR even if other TSRs were  
installed later depending on the type of these TSRs.

Regards,
Christian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Lucas Kiwi]

Christian,

   Thanks again.



>
> Your interface (as I understand it) isn't that different.
> Somewhere you 
> have to dispatch into different modules.
>

   Yeah, but I don't do it sequentially, but using a lookup table. Anyway, I've just been putting deeper attention to AMIS and I realised that I can actually do this thing under AMIS as well. Although the AMIS interface itself would not handle it, my TSR can do it.. The interface I was suggesting would manage the modules completely, so each module would not need to have code for administration purposes at all... however, this is not a drawback unless there are really many things loaded together in AMIS at the same time.

>
> If you're interested, I could send you descriptions and
> example source of 
> some TSRs and AMIS implementations that I worked out with
> Bret. This TSR 
> installation method always allows the program to install
> its resident part 
> into the best location. Installation into a UMB works
> without LOADHIGH. 
> The deinstallation method allows to remove the TSR even if
> other TSRs were 
> installed later depending on the type of these TSRs.
>

   That would be very useful. Thanks.
   I have been fighting trying to get the two systems work together, but I believe it is actually to messy and unnecessary. I will start the development only under the AMIS interface for now, so I don't waste time with the multiplexing scheme and go directly to the kicks.
   As I was saying before, to make it more comfortable and faster, I will try to put everything in registers, but still I will enable a function so that parameters can also be passed in a memory block. Do you reckon it will be OK if I use 32bit registers to pass parameters with the AMIS interface?

               Lucas



     


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel