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