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