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

Reply via email to